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

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

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

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. Провести анализ востребованности будущего продукта.
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 (

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

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

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

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

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. Чем отличается стратегия «белого ящика» в тестировании от стратегии «черного ящика»?

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

Рис. 26.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВНИМАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВНИМАНИЕ

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

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

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

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

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

Рис. 26.2.

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

Этапы разработки программ

Моделирование – исследование каких либо явлений или систем путем построения и изучения их моделей.

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

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

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

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

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

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

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

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

Шестой этап - перенос программы на машинный носитель. При работе на ПК программа и исходные данные вводятся с клавиатуры.

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

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