Этапы разработки программ. Порядок разработки программы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Какие классы программных ошибок вы знаете и когда они выявляются?