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

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

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

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

1. Быстрая смена вычислительной техники и алгоритмических языков;

2. Не стыковка ЭВМ друг с другом (VAX и IBM);

3. Отсутствие полного взаимопонимания между заказчиком и исполнителем к разработанному программному продукту.

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

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

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

1) постановка задачи;

2) проектирование программы

3) построение модели

4) разработка алгоритма;

5) написание программы;

6) отладка программы;

7) тестирование программы;

8) документирование.

Кратко остановимся на каждом из этих этапов.

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

Как определить решение;

Каких данных не хватает и все ли они нужны;

Какие сделаны допущения и т. п.

Таким образом, кратко можно сказать, что на этапе постановки задачи необходимо:

Описание исходных данных и результата;

Формализация задачи;

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

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

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

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

Методы проектирования архитектуры делятся на две группы:

1)ориентированные на обработку

2)ориентированные на данные.

Методы, ориентированные на обработку , включают следующие общие идеи.

а) Модульное программирование.

Основные концепции:

Каждый модуль реализует единственную независимую функцию;

Имеет единственную точку входа/выхода;

Размер модуля минимизируется;

Каждый модуль разрабатывается независимо от других модулей;

Система в целом построена из модулей.

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

б) Функциональная декомпозиция.

Подобна стратегии «разделяй и управляй». Практически является декомпозицией в форме пошаговой детализации и концепции скрытия информации.

в) Проектирование с использованием потока данных.

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

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

г) Технология структурного анализа проекта.

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

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

а) Методология Джексона.

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

б) Методология Уорнера.

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

в) Метод иерархических диаграмм.

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

г) Объектно-ориентированная методология проектирования.

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

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

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

Рис. 3.1. Схема построения модели при дедуктивном способе

При дедуктивном подходе (рис. 3.1) рассматривается частный случай общеизвестной фундаментальной модели. Здесь при заданных предположениях известная модель приспосабливается к условиям моделируемого объекта. Например, можно построить модель свободно падающего тела на основе известного закона Ньютона ma = mg – F сопр и в качестве допустимого приближения принять модель равноускоренного движения для малого промежутка времени.

Рис. 3.2. Схема построения модели при индуктивном способе

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

Технология построения модели при индуктивном способе:

1) эмпирический этап

Умозаключение;

Интуиция;

Предположение;

Гипотеза.

2)постановка задачи для моделирования;

3)оценки; количественное и качественное описание;

4)построение модели.

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

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

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

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

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

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

Выделяют три базовых структурных элемента (управляющие структуры): композицию, альтернативу, итерацию.

Композиция – это линейная конструкция алгоритма, составленная из последовательно следующих друг за другом функциональных вершин:

begin S1; S2; end

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

if B then S1 else S2

и неполной развилки:

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

и с постусловием:

repeat S1 until B

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

Процесс структурного программирования обычно начинается с разработки блок-схемы.

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

Для иллюстрации технологии структурного программирования сверху-вниз рассмотрим пример.

Пример. Технология разработки программы решения квадратного уравнения.

На рис. 3.3 проиллюстрирована пошаговая детализация процесса построения алгоритма. Заметим, что для начального шага разработки программы имеем в качестве входных данных коэффициенты а, b, с квадратного уравнения ах 2 + bх + с = 0, а на выходе - значения двух корней х1, х2.

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

На этапе написания программы по разработанному алгоритму на выбранном языке программирования составляется программа.

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

Тестирование - это процесс исполнения программ с целью выявления (обнаружения) ошибок.

Существуют различные способы тестирования программ.

Тестирование программы как «черного ящика» (стратегия «черного ящика» определяет тестирование с анализом входных данных и результатов работы программы). Критерием исчерпывающего входного тестирования является использование всех возможных наборов входных данных.

Тестирование программы как «белого ящика» заключается в стратегии управления логикой программы, позволяет использовать ее внутреннюю структуру. Критерием выступает исчерпывающее тестирование всех маршрутов и управляющих структур программы.

Разумная и реальная стратегия тестирования - сочетание моделей «черного» и «белого ящиков».

Принципы тестирования:

Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора;

Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных;

Необходимо проверять не только делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать;

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

Инспекция и сквозной просмотр - это набор процедур и приемов обнаружения ошибок при чтении текста.

Основные типы ошибок, встречающихся при программировании:

Обращения к переменным, значения которым не присвоены или не инициализированы;

Выход индексов за границы массивов;

Несоответствие типов или атрибутов переменных величин;

Явные или неявные проблемы адресации памяти;

Ошибочные передачи управления;

Логические ошибки.

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

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

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

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

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

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

Контрольные вопросы

1. Перечислите этапы создания программ.

2. Что выполняется на этапе постановки задачи?

3. Что представляет собой декомпозиция?

4. Какие принципы используются на этапе построения модели?

5. На каких принципах основано структурное программирование?

6. Какие базовые структурные элементы выделяют в структурном программировании?

7. Какие две формы итерации (как элемент структурного программирования) вы знаете?

8. Что собой представляет идея структурного программирования сверху-вниз?

9. Что собой представляет идея структурного программирования снизу-вверх?

10. Что такое отладка программы?

11. Какие классы программных ошибок вы знаете и когда они выявляются?

12. Назначение тестирования программы?

13. Какие способы тестирования вы знаете?

14. Чем отличается стратегия «белого ящика» в тестировании от стратегии «черного ящика»?

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

1. Определение входных и выходных данных, требований к программе.

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

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

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

3. Кодирование (программирование).

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

4. Компиляция и отладка.

Исходный текст на Паскале не будет непосредственно исполняться компьютером -- для работы программы ее требуется откомпилировать , т. е., перевести в машинный код. Эту работу выполняет специальная программа-компилятор или оболочка языка. Оболочка Паскаля, с помощью которой мы будем разрабатывать свои программы, называется Turbo Pascal 7.1, она разработана компанией Borland International в 1983-97 гг. В результате преобразования компилятором исходного текста программы в машинный код получается исполняемый файл с расширением exe, который можно запустить (выполнить ) в той операционной системе (ОС), для которой разработан компилятор. Наша оболочка Паскаля создавалась для ОС MS-DOS, однако, в современных ОС семейства Windows программа, написанная на Паскале, работать все же будет, правда, без удобных интерфейсных возможностей Windows.

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

Возможны программные ошибки трех видов:

· синтаксические (ошибки в правилах языка);

· алгоритмические (ошибки в логике программы);

· ошибки времени исполнения , возникающие в процессе работы запущенной программы.

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

5. Тестирование.

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

6. Документирование и поддержка.

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

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

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

• анализ требований к проекту;
• проектирование;
• реализация;
• тестирование продукта;
• внедрение и поддержка.

Анализ требований к проекту

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

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

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

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

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

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

Реализация

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

Тестирование продукта

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

Результатом тестирования является устранение всех недостатков системы и заключение о ее качестве.

Внедрение и поддержка

Внедрения системы обычно предусматривает следующие шаги:

• установка системы,
• обучение пользователей,
• эксплуатация.

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

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

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

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

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

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

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 и делятся на три группы (без привязки ко времени) :

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

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

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

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

Анализ осуществимости

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

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

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

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

1. Определение проблемы.

2. Альтернативные решения и ожидаемые от них преимущества.

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

Выявление, понимание и спецификация требований

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

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

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

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

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

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

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

Ниже приведен возможный перечень пунктов документа спецификации требований, который может быть руководством специалиста по программному обеспечению:

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

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

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

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

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

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

Кодирование и тестирование модулей

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

Сборка и системное тестирование

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

Комплексное тестирование включает в себя тестирование наборов модулей по мере их объединения, при условии предварительного тестирования каждого модуля в отдельности.

Поставка, развертывание и сопровождение ПО

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

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

Другой тип классификации затрат на сопровождение был описан в работе Линца (Lienz) и Свонсона (Swanson) в 1980 г. Их анализ показал, что по­рядка 42 % затрат относятся на внесение изменений в требования пользова­телей, 17 % - на изменение формата данных, 12 % - на устранение ава­рийных неполадок, 9 % - на отладку процедур, 6 % - на модификацию аппаратных средств, 5 % - на исправление документации, 4 % - на повышение производительности и остальное - на прочие причины.

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

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

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

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

Контрольные вопросы

1. Что такое жизненный цикл ПО?

2. Какой нормативный документ регламентирует ЖЦ ПО?

3. На каких трех группах процессов базируется структура ЖЦ ПО?

4. Опишите процесс разработки ЖЦ ПО

5. Опишите процесс эксплуатации ЖЦ ПО

6. Опишите процесс управления проектом ЖЦ ПО

7. Опишите процесс управления конфигурацией ЖЦ ПО

8. Опишите этапы процесса проектирования ЖЦ ПО

9. Каким требованиям должна удовлетворять функциональная спецификация?

10. Опишите основные характеристики и структуру каскадной модели ЖЦ

11. Назовите недостатки каскадного подхода

12. Изобразите схему реального процесса создания ПО

13. Опишите основные характеристики и структуру спиральной модели ЖЦ

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

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

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

17. Дайте определение спецификации ПО. Из каких пунктов может состоять этот документ?

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