Бюджетная система РФ

Рис. 13.1. Этапы разработки приложений

Заметим, что разработка программного обеспечения (ПО) - итерационный процесс, некоторые этапы которого могут перекрываться.

Рабочие группы и функции участников проекта.

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

Скорость - быстрое получение промежуточных результатов;

Использование опыта членов группы - разрешение вопросов с использованием опыта всех членов группы.

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

Эффективность организационной структуры;

Степень важности проекта;

Уровень профессионализма членов группы.

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

Функции участников проекта.

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

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

Промежуточные результаты и их контроль.

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

Выявить требования.

Разработать проект в общих чертах.

Определить план разработки.

Разработать альфа-версию.

Разработать бета-версию.

Разработать окончательную версию.

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

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

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

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

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

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

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

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

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

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

Выявлены ли потенциальные пользователи опытной версии? Если нет, то как их определить?

Сколько требуется пользователей для тестирования опытной версии? Кто будет отвечать на их вопросы и обрабатывать отзывы?

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

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

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

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

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

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

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

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

Зачем нужен продукт или средство?

При решении какой задачи планируется использовать продукт или средство?

Как решается эта задача в настоящее время? Что заказчику нравится или не нравится в способе решения задачи?

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

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

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

В каких операционных средствах должна работать программа? Какие операционные системы и аппаратные средства имеют пользователи?

Работают ли пользователи в локальной вычислительной сети? Соединены ли они с Internet или intranet?

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

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

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

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

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

Создание модели объектов. Модель объектов наиболее полезна при использовании объектно-ориентированных инструментов разработки.

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

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

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

Для создания модели данных:

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

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

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

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

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

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

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

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

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

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

Является ли разбивка на объекты оправданной и интуитивной?

Облегчают ли действия пользователей объекты и связанные с ними задачи?

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

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

Облегчает ли интерфейс действия пользователя?

Являются ли поведение и внешний вид прототипа интуитивными для пользователей?

Имеются ли средства повышения скорости работы с приложением?

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

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

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

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

Технический проект определяет главные технологические компоненты и их взаимосвязь. В объектно-ориентированном приложении наименьшими составляющими технического проекта являются интерфейс и связанный с ним код, источники информации, а также другие компоненты, с помощью которых обеспечивается взаимодействие между интерфейсом и данными. Интерфейс можно разработать в Visual Basic, HTML, или Visual C++. Источниками данных могут служить Microsoft Access, источники данных ODBC, например, база данных SQL Server, текстовые файлы или документы других приложений, например, рабочий лист Microsoft Excel или документ Microsoft Word. Компонентами управления данными могут быть объекты OLE Automation, библиотеки ODBC, объекты доступа к данным, либо ядро Visual Basic Jet.

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

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

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

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

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

Протестировать программу.

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

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

Документирование программного продукта. Составление документации по программному продукту необходимо начинать на этапе разработки.

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

наименование и перечень формальных параметров;

назначение процедуры и выполняемые ей действия, в особо сложных случаях - блок-схему;

описание и назначение входных параметров и их предельные значения;

перечень и описание локальных переменных;

описание и назначение выходных параметров и их предельные значения;

результаты работы процедуры.

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

Для недавнего времени документация выходила в напечатанном виде. Однако сейчас описание программ распространяется, используя электронные средства, что позволяет намного проще и дешевле обновлять документацию. С программным продуктом можно связать справочные файлы, обеспечивая при выполнении задач конспектную подсказку. Кроме того, имеется возможность встроить в продукт мастера и обучающие программы. При написании руководств можно использовать несколько приложений. Например, если требуется создать справочные файлы, используйте Microsoft Word или Microsoft Help Compiler. Чтобы создать файлы HTML, применяется редактор HTML. Microsoft Help Compiler поставляется вместе с профессиональной версией Visual Basic.

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

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

Запись на магнитный носитель и поставка программного продукта.

С самого начала работы над программным продуктом необходимо принять решение о том, как распространять систему: на дискетах или CD-ROM, либо переслать ее через Internet или intranet, либо просто установить ее на совместно используемом диске.

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