Сравнение стандартов и методологий разработки КИС

В процессе разработки необходимо личное общение заказчика с разработчиками.
Четкая мотивация разработчиков при работе над проектом. Создание дружественной и доверительной атмосферы в коллективе.
Способ передачи материалов – личный разговор.
Работающее ПО – лучший показатель прогресса.
Поддержание постоянного темпа работы в течение неопределенного срока со стороны спонсоров, разработчиков и пользователей.
Непрерывное отслеживание качества кода и удобства пользования программным продуктом.
Возможность использовать в работе существующие наработки.
Самостоятельная организация проектной команды способствует лучшим техническим требования, дизайну и архитектуре.
Способность постоянно подстраиваться под новые обстоятельства.
Подход Agile предполагает активное использование технологий занимает в процессе создания ПО. Технология повышает производительность работы команды разработчиков при выполнении следующих условий:
Технология является средством, позволяющим людям легче выражать свои мысли.
Технология позволяет выполнять задачи, невыполнимые вручную.
Технология призвана автоматизировать однообразные и склонные к ошибкам действия.
Необходимо отметить, что методология быстрой разработки не не является универсальным подходом к разработке программного обеспечения. Данная методология применима только к проектам определенного уровня. Согласно А. Коберну характеристиками, позволяющими отнести проект к некоторому уровню, являются критичность и масштаб. Критичность определяет последствия, к которым могут привести дефекты в структуре ПО. Уровни критичности проекта имеют следующую градацию [12]:
C-дефекты связаны с недостатком удобства в работе с системой.
D-дефекты могут привести потерю средств, которые можно возместить.
E-дефекты могут привести к потере средств, которые нельзя возместить.
L-дефекты создают угрозу человеческой жизни.
Масштаб проекта определяется количеством участвующих в нем разработчиков и определяется так:
от 1 до 6 человек – малый масштаб.
от 6 до 20 человек – средний масштаб.
свыше 20 человек – большой масштаб.
Согласно Коберну, быстрая разработка должна использоваться исключительно в проектах малого и среднего масштаба с низким уровнем критичности. Приведем общие принципы для оценки технологий, применяемых в таких проектах:
Интерактивность взаимодействия между всеми участниками проекта с целью обмена информацией.
Перегрузка проекта избыточной сложностью отрицательно влияет на результат.
Команда с малым числом разработчиков легче адаптируется к изменениям в процессе разработки.
Критичные проекты требуют повышенной формальности в отношениях.
Непрерывная обратная связь сокращает потребность в промежуточных и конечных продуктах.
Противопоставление дисциплины, понимания и опыта формальному процессу и строгому документированию.
Снижения производительности системы в пользу простоты решения допустимо в некритичных проектах.
2.7. Методология RAD
Методы быстрой разработки приложений (Rapid Application Development, RAD) являются типовым универсальным инструментом разработки при создании приложений, обладающих интерфейсом пользователя. Кроме того, метод RAD является идеальным средством создания прототипирования [6]. Данные средства имеют в своем составе средства и технологии для разработки распределенных приложений. Основным достоинством методологии RAD является возможность визуального проектирования приложения и наличие обширной библиотекой стандартных объектов и интерфейсов. Для сред RAD свойственно многократное использование объектов и стандартных библиотек. Помимо перечисленных достоинств RAD позволяет легко создавать массивы объектов, а также обладает инструментами автоматической сборки программы из модулей и компонентов и отладчиком.
Модель быстрой разработки приложений представляет собой пример использования инкрементной стратегии проектирования (рис. 5).

Рис. 5. Модель быстрой разработки приложений RAD.

Модель позволяет обеспечить максимально короткий цикл разработки приложения. Ключевыми характеристиками методологии RAD являются высокая скорость адаптации последовательной модели, использующей в качестве основного средства разработки компонентно-ориентированное конструирование. В условиях полного детерминизма требований и ограниченности проектной области разработки, модель RAD позволяет группе создать полнофункциональную систему за очень короткое время (60-90 дней). RAD-подход направлен на разработку корпоративных информационных систем и включает в себя следующие этапы:
Моделирование бизнес-функций, что позволяет ответить на вопрос о том, какая информационная единица является ключевой для данного бизнес-процесса. Кроме этого, целью данного этапа является определение роли информации в структуре КИС.
Моделирование информационного потока и отображение ключевых объектов приложения в модели, наделенные определенным набором атрибутов, и необходимые для поддержания бизнеса. Данный этап характеризуется установлением связей и отношений между всеми объектами системы.
Моделирование интерфейсов приложения, определяющих трансформации объектов данных, обеспечивающие реализацию функций. Обработка данных нацелена на реализацию основных операций обработки добавления, обновления, удаления и выборку объектов данных.
Генерация приложения предполагает применение языков программирования, 4-го поколения. По сравнению с методологиями, использующими для создания программного продукта языки программирования 3-го поколения, методология RAD опирается на создание и повторное использование программных компонентов. Кроме того, для целей сборки приложения из отдельных компонентов используются утилиты автоматизации.
Тестирование и сборка компонентов в цельное приложение. Данный этап отличается от тестирования, проводимого при использовании других методологий разработки тем, что используемые программные компоненты уже протестированы. Это обстоятельство позволяет значительно сократить необходимое для тестирования системы.
Методология RAD предполагает, что разработка ПО ведется небольшой группой разработчиков. Сроки разработки обычно составляют три-четыре месяца. Экстремально короткие сроки разработки достигаются за счет активного применения инкрементного прототипирования и средств визуального моделирования.
Методология RAD предполагает, что заказчик принимает активное участие в процессе разработки с первых этапов, т.е. с формирования требований к корпоративной информационной системе. Участие заказчика обуславливает полное соответствие конечного программного продукта исходным функциональным требованиями, а также возможность изменять требования уже в период разработки. Готовый программный продукт должен сопровождаться качественной документацией, обеспечивающей удобство эксплуатации и сопровождения системы. Последнее требование приводит к сокращению дополнительных затрат на сопровождение. В целом модель RAD позволяет значительно сократить время, требуемое для разработки приложения от начала работ до получения продукта, удовлетворяющего требованиям заказчика.

Заключение
Исследования процессов разработки информационных систем показывает, что подавляющее большинство проектов КИС не соответствуют заявленным требованиям качества, срокам и заложенной смете. Около 40% проектов завершаются, не будучи доведенными до конца. Причина подобных провалов кроется, как правило, в несовершенствах методов управления проектом.
Методология разработки корпоративных информационных систем находится на стадии своего становления как отдельной области исследований, о чем свидетельствует появление отдельной дисциплины, под названием программная инженерия. Для целей стандартизации подходов к разработке программных систем были созданы регламенты и стандарты, определяющие прядок работ на всех этапах жизненного цикла программного продукта. Существующие стандарты различаются между собой по области применимости. Каждый подход имеет право на существование и содержит множество примеров, когда проект завершился успешно или неуспешно.
Выбор конкретной методологии в каждом случае исходит из адаптации ее к данному конкретному проекту. Стандарты позволяют представить перечень работ, проводимых на всех этапах жизненного цикла. Общим недостатком существующих стандартов является то, что изложение методов приводится на концептуальном уровне без детализации и привязки к конкретным средствам разработки. Возможность адаптации некоторой методологии подразумевает составление на ее основе полного перечня процессов и работ, необходимых для реализации конкретного проекта.
Ключевыми факторами, влияющими на выбор конкретной методологии, являются: масштаб и критичность проекта. Масштаб проекта позволяет судить о его сложности. В настоящее понятие «сложность проекта» является скорее эмпирическим, чем строго определенным. Другим фактором, влияющим на выбор методологии, служит возможность использования при разработке программного продукта готовых модулей.
Стандарт ГОСТ Р 12207 определяет две крайние характеристики информационных систем в качестве критерия для их классификации – готовое и неготовое. Однако характер проекта может позволить использовать уже готовые программные компоненты в процессе разработки. Сложность выбираемой методологии определяется тем, какие готовые компоненты можно применять в процессе работы над проектом. Число базовых модулей, как правило, обратно пропорционально сложности проекта.
Современная корпоративная информационная система разрабатывается людьми разных профессий. Каждый участник процесса вносит свой вклад в общее дело. Каждый работник имеет свой опыт, свое понимание процессов и свои методы решения задач. Качественное программное обеспечение появляется тогда, когда это менеджеру проекта удается наилучшим образом соединить в команде самые развитые качества работников и направить их на цели, заложенные в проекте. Умение руководителя организовать работу персонала и скоординировать труд всех участников процесса позволяет добиться высокого качества выпускаемого программного продукта, удовлетворяющие всем требованиям заказчика.

Список литературы
ГОСТ 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем.
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы (КСАС). Техническое задание на создание автоматизированной системы.
ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы (КСАС). Автоматизированные системы. Стадии создания.
ГОСТ Р ИСО/МЭК 12207-99 Информационная Технология. Процессы жизненного цикла программных средств.
Благодатских В.А. Стандартизация разработки программных средств. – М.: Финансы и статистика, 2006.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2005.
Липаев В.В. Программная инженерия. Методологические основы. – М: ТЕИС, 2006.
Орлов С.А. Технологии разработки программного обеспечения. – СПб.: Питер, 2002.
Котляров В.П. Основы тестирования программного обеспечения. – М.: БИНОМ. Лаборатория знаний, 2006.
Шафер Д, Фатрел Р, Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. – М.: Вильямс, 2003.
Новикова Г.М. Основы разработки корпоративных инфокоммуникационных систем. – М.: РУДН, 2008.
Фаулер М. Архитектура корпоративных программных приложений. М.: Издательский дом «Вильяме», 2006.











2