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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) Разработка плана, в котором раскрывается стра­тегия решения (стратегия достижения цели);

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

4) Проверка правильности решения;

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

6) Сдача решения потребителю.

Эти этапы применительно к программированию называ­ют соответственно так:

1) определение требований к ПО и целей проектирования ПО (постановка задачи, ее формализация и разработка ТЗ);

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

3) кодирование (написанием собственно программы на выбранном языке программирования) и отладка программы;

4) тестирование программы, в том числе и на стороне Заказчика (по ПМИ);

5) выпуск документации (руководство программиста, руководство системного программиста и т.п.);

6) выпуск программного продукта для передачи потребителю (Заказчику).

По ГОСТ 19.102-77 «Стадии разработки» определены следующие этапы разработки ПО:

1) разработка ТЗ (ему соответствует названный выше этап «Постановка задачи и ее формализация»)

2) разработка ЭП (им соответствует названный выше этап «разработка метода решения,

3) разработка ТП структуры программы и алгоритмов»)

4) разработка РП (он включает названные выше этапы «Кодирование и отладка», «Тестирование» и «Документирование».

5) внедрение (ему соответствует названный выше этап «Выпуск программного продукта для передачи потребителю (Заказчику)»).

Более подробно о некоторых этапах (или подэтапах) разработки ПО.

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

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

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

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

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

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

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

Теория графов;

Теория вероятностей;

Теория массового обслуживания;

Теория множеств

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

Хорошая математическая постановка задачи часто позволяет сразу увидеть способ решения .

Поиск метода решения задачи (на этапе проектирования)

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

Те, которые уже ранее встречались, и решение их уже известно;

Те, для которых известна постановка, и решение их не представляет (для программиста) труда.

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

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

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

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

Объектно-ориентированная (по сути тоже восходящий подход, но не процедурный);

Логическая (логико-ориентированная);

Функциональная.

Мы об этих парадигмах поговорим чуть позже.

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

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

2).Подготовка программы для ПЭВМ , т.е. перенос рукописного текста программы с бумаги на машинный носитель информации. Для этого используется текстовый редактор.

3).Компиляция текста программы в машинный код с помощью программы, называемой компилятором.

ЭВМ

Машинный код

(понятен ЭВМ)

Замечание : фраза, что программа – это алгоритм, составленный на языке, понятном ЭВМ , означает, что при наличии посредника-компилятора текст, написанный на ЯВУ, уже считается понятным ЭВМ. Этот посредник-компилятор занимается переводом текста программы с ЯВУ на машинный язык.

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

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

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

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

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

Замечание: компилятор Турбо-Паскаля (и Free Pascal) производит компиляцию сразу в исполняемый код (отдельный этап линковки не требуется).

Все адресные ссылки в загрузочном модуле - относительны (относительно начала загрузочного модуля). Перед передачей программе управления надо настроить все адресные ссылки на начальный адрес размещения программы в оперативной памяти. Эту функцию выполняет Загрузчик .

Отладка и Тестирование: После получения готового к выполнению кода программы начинается этап ее отладки и тестирования - поиск ошибок в программе (debugging), например, ошибок при работе с данными, логических ошибок и т.п.

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

Различают методы тестирования : а) белого ящика (структурное тестирование) и б) черного ящика (функциональное тестирование - может начинаться сразу после получения ТЗ).

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

По завершении (успешном) тестирования программа готова к передаче ее заказчику.

Замечание:

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

4. Средства записи и классификация алгоритмов .

Если вы не знаете, в каком направлении развивать проект, то он вряд ли выберет нужный путь самостоятельно.
Стив Макконнелл

Введение

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

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

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

Для достижения поставленных целей заказчику и исполнителю совместно нужно решить ряд вполне определённых задач:

1. На основе исходной идеи сформулировать цели и задачи будущего проекта.
2. Разработать некоторое исходное видение – концепцию проекта.
3. Провести анализ востребованности будущего продукта.
4. Провести предварительную оценку рисков будущего проекта.
5. На основе концепции и списка предварительных рисков подготовить предварительное техническое решение.
6. Выбрать методологию разработки и подготовить предварительный план работ.
7. Провести предварительную оценку трудозатрат и необходимых ресурсов.
8. Провести анализ реализуемости продукта.
9. Провести независимое рецензирование технического решения.
10. Принять решение о том, стоит ли продолжать работы.

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

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

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

Рисунок 1. Деятельность участников проекта на предварительном этапе.

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

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

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

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

Формулирование цели и задач будущего проекта

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

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

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

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

Как правило, именно заказчик, как носитель идеи проекта, формулирует цель и задачи. Но в моей практике был случай, когда эту работу пришлось выполнять нам, исполнителям. Нам предстоял тендер на разработку одной весьма специфической системы для некой правительственной службы. Такие проекты имеют особенность: службе «сверху» даётся поручение разработать некоторую систему и сопровождать её, но сама служба, как правило, не является пользователем системы. Естественно, руководство службы берёт под козырёк и объявляет конкурс. Но никто в самой службе не знает, для какой цели и как будет использоваться разрабатываемый продукт. И, что хуже всего, никто не стремится это знать. В таких условиях исходное видение системы у заказчика (правительственной службы) отсутствует почти полностью. Ни цели, ни задачи проекта заказчик сформулировать не может. Нам пришлось самим облазить всё оборудование заказчика, разыскать нужную техническую документацию и выйти на конечных пользователей в различных правительственных ведомствах. В конечном итоге, мы успешно выполнил проект, получили прибыль, неплохой опыт и, что немаловажно, рекомендации заказчика. Однако такое положение, всё же, - исключение. Цели и задачи проекта должен формулировать именно носитель идеи.

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

Почему изложенные выше вопросы важно решить в самом начале?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка концепции проекта

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

Года два назад одна из команд департамента, где я работал в то время, должна была подготовиться к тендеру на разработку очень большой и сложной системы для одной из ведущих транспортных компаний России. Я в то время работал над другими проектами. Однако спустя некоторое достаточно продолжительное время после начала работ руководитель проекта обратился ко мне за помощью. Проблема проекта была в том, что никто из участников не понимал, как должна работать система. Возможно, в этом виноват масштаб системы и отсутствие опыта у команды для работы со столь сложными проектами. Но первое, что я нашёл, начав погружаться в тему, - полное отсутствие у команды уверенности в успехе. И второе – отсутствие понимания, как вообще взяться за проект. Несмотря на то, что прошло уже более месяца, главным вопросом оставался один: что спросить у заказчика, чтобы хотя бы начать работу?

Смешного тут ничего нет. Каждый специалист чаще всего является специалистом в своей области. Здесь же требовался человек, который мог бы впитать в себя весь гигантский объём ожиданий заказчика и при этом имел достаточно опыта разработки сложных информационных систем, чтобы выразить идею заказчика в виде реалистичного решения. Чем больше объём будущей системы, тем больше требуется навыков и знаний от разработчика концепции. Если в команде не оказывается такого специалиста, проект буксует. В наших проектах за разработку и дальнейшее сопровождение концепции отвечает системный архитектор. Он же отвечает за то, чтобы продукт реализовывался в точном соответствии с концепцией. И я не советую привлекать на эту позицию разработчиков, пусть даже опытных: очень редко талант написания качественного кода сочетается с умением вести диалог с заказчиком, и ещё реже программист желает подчиняться концепции.

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

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

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

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

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

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

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

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

Вдохните дух концепции в ваш проект, заботьтесь о его здоровье и никогда его не теряйте.

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

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

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

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

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

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

Разработчик концепции должен ответить на следующие вопросы:

1. Будет ли система распределённой географически? Если да, то на какие компоненты она будет разделена и где каждый компонент будет/может быть развёрнут? Какие каналы связи между распределёнными компонентами будут/могут использоваться? Имеются ли каналы связи в наличии у заказчика, или их предстоит создать? Будут ли каналы связи собственными, или они будут арендоваться? Кто будет ответственным за аренду каналов связи: заказчик или исполнитель?
2. Какие программные средства будут входить в каждый компонент системы? Как отдельные программные средства будут взаимодействовать между собой в составе компонента системы?
3. Какая аппаратная и программная платформа будет использоваться для развёртывания каждого программного средства системы? Будет ли исполнитель отвечать за закупку, развёртывание и сопровождение среды выполнения?
4. Какие из сформулированных заказчиком задач будет решать то или иное программное средство? Как оно будет решать поставленные задачи? Как будут обеспечиваться функциональные показатели качества системы?
5. Как будет осуществляться взаимодействие программных средств системы с пользователем и внешними информационными системами? Какие интерфейсы и сервисы система будет предоставлять наружу? Как будут обеспечиваться нефункциональные показатели качества?
6. В конечном счёте, главный вопрос: как система в целом будет решать поставленные заказчиком задачи с учётом установленных ограничений?

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

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

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

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

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

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

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

Анализ востребованности разрабатываемой системы

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

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

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

При разработке инвестиционного ПО или ПО, обеспечивающего жизненно важные потребности собственного бизнеса, анализ востребованности приобретает особый вес. Помнится, в далёком 2008-м году я вёл переговоры с руководителем службы безопасности АФК «Система», который пытался заставить нас внести в наш «коробочный» продукт особый функционал. Он был очень удивлён, когда встретил мой твёрдый отказ. Но у меня были на то причины: у нас были тысячи клиентов, и изменения в нашем ПО затрагивали их интересы. Внедрив в нашу систему специфические функции, мы приобрели бы одного нового потребителя, но потеряли бы сотни. Я объяснил своему собеседнику нашу позицию. В конечном итоге, мы поставили в АФК нашу систему безопасности почти в исходном виде, добавив лишь небольшой плагин. И за свою работу команда получила благодарственное письмо от руководства этой известной организации.

Если вы видите, что выполнение проекта нарушает интересы вашего бизнеса, откажитесь от него. Для вас, как исполнителя, каждый проект должен быть либо ступенькой в развитии бизнеса, либо надёжной страховочной опорой «на чёрный день». Если проект не станет ни тем, ни другим, на него не стоит тратить своё внимание.

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

Предварительная оценка рисков и неопределённостей проекта

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

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

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

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

Подготовка предварительного технического решения

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

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

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

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

Предварительное техническое решение должно содержать указание на аппаратное и программное обеспечение, которое потребуется приобрести для обеспечения разработки или эксплуатации разрабатываемой системы. Например, для работы с криптографическими алгоритмами ГОСТ Р 34.10/34.11-2001, используемыми для создания и проверки электронной цифровой подписи, может понадобиться лицензия на криптопровайдер, который поддерживает эти алгоритмы. Если планируется использовать управляемый код, то в дополнение к криптопровайдеру может потребоваться дополнительное программное обеспечение. Другой пример – библиотеки визуальных компонентов для пользовательского интерфейса. В ряде случаев потребуется закупать аппаратное обеспечение для развёртывания системы. Расходы на подобные закупки могут быть весьма существенными и обязательно должны оцениваться при анализе реализуемости разрабатываемого ПО.

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

Выбор методологии разработки продукта

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

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

Подготовка предварительного плана работ

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

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

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

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

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

Длительность задачи должна учитывать время, реально затрачиваемое на её решение, а не «идеальные» часы. Хорошие результаты даёт использование фокус-фактора при получении реальных оценок. В данном случае фокус-фактор я заимствую из практик agile, где он определяется как количество «идеальных» часов, отводимых на решение комплекса задач, делёное на количество времени, реально затраченного на решение . Так, если в идеале на реализацию некоторой задачи программист потратил бы 4 часа, то, используя фокус-фактор 0,55, получим реальную длительность работы над задачей почти 7,5 часов. Разница значительная, и её обязательно нужно учитывать.

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

Удобно выразить длительности и зависимости задач с помощью диаграммы Ганта . Это даст представление о том, какие задачи могут или должны выполняться параллельно (и, соответственно, для них нужны разные исполнители), а какие – последовательно. Появится возможность выявить критические цепочки задач и попытаться их оптимизировать. Также такое представление даст сроки, к которым следует набирать персонал или развёртывать/обновлять/освобождать компоненты инфраструктуры проекта.

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

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

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

Обычно, я даю оценки по этапам для каждого исполнителя и каждого ресурса с указанием процента их занятости, затем даю итоговую общую оценку. Например, для этапа реализации небольшого проекта может потребоваться участие архитектора (50% его времени), аналитика (25%), администратора, сопровождающего инфраструктуру (10%) и трёх разработчиков с полной занятостью. Этап длится 6 недель (30 рабочих дней), так что архитектор будет занят 15 дней, аналитик – 7, администратор – 3, а каждый из разработчиков – все 30 дней. На основе этих трудозатрат можно рассчитать расходы на персонал. На те же 30 дней команде нужны система трекинга задач, система контроля версий, пара виртуальных машин для тестирования, виртуальная машина с развёрнутой СУБД и что-то ещё, специфичное для проекта. Кроме того, нужна лицензия на использования криптопровайдера, сертификаты и контейнеры закрытых ключей для каждого стенда и персонально для каждого разработчика, чтобы можно было использовать цифровую подпись.

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

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

Анализ реализуемости технического решения

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

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

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

Как не трудно понять, речь идёт о внутреннем экспертном рецензировании предлагаемого решения и сделанных для него оценок. Часто к такому рецензированию привлекаются опытные специалисты различных подразделений исполнителя: аналитиков, архитекторов, администраторов, программистов. Совместно они должны решить большой круг вопросов. Может ли отдел администрирования предоставить необходимую инфраструктуру? Нужно ли докупать для этого оборудование или программное обеспечение? Имеется ли требуемый персонал и будет ли он свободен от других проектов в нужные сроки? Имеются ли у специалистов исполнителя нужные знания и навыки? Будут ли привлекаться новые специалисты в штат? Будут ли привлекаться аутсорсеры?

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

Независимое рецензирование предварительного решения

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

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

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

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

Завершение подготовительного этапа – подписание договора

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

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

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

Итог

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

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

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

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

Список литературы

1. Максим Кузнецов. Обзор процесса разработки программного обеспечения – habrahabr.ru, 2015 (

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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