АЛГОРИТМ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОТ ТРЕБОВАНИЙ ДО РЕАЛИЗАЦИИ

INFORMATION SYSTEM DEVELOPMENT ALGORITHM FROM REQUIREMENTS TO IMPLEMENTATION

Pavel Mitkevich

student, Department of "Information Systems of Digital Economy", Institute of Economics and Finance, Russian University of Transport,

Russia, Moscow

Larisa Kargina

Scientific Supervisor, Doctor of Economics, Professor, Department of "Information Systems of Digital Economy", Institute of Economics and Finance, Russian University of Transport,

Russia, Moscow

АННОТАЦИЯ

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

ABSTRACT

This article will discuss modern ways of developing specifications and requirements for software. The algorithm of software product development is shown. All stages of the project implementation are described. Some implementation problems and ways to solve them are identified.

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

Keywords: electronic document management, SAP ERP, Unified Procurement Information System.

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

• анализ требований предметной области
• системный анализ
• проектирование и реализация
• сопровождение и развитие

О важности анализа требований говорят нам современные исследования проектов [1], связанных с программный обеспечением, которые показывают нам что:

• 31% проектов – остановлены до завершения
• 53% проектов стоили 189% от первоначальной̆ оценки
• В крупных компаниях 9% проектов выполнено в срок и без превышения бюджетов.
• В мелких компаниях 16% проектов выполнено в срок и без превышения бюджетов.

Источниками ошибок считают [1]:

• Недостаточное количество информации от пользователей - 12,8%
• Неполные спецификации - 12,3%
• Изменения требований - 11.8 %

Отчет показывает нам, что составление правильных требований к проекту сокращает издержки компании-заказчику и делает процесс разработки проще. Самими же требования можно считать [2]:

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

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

Существует два основных типа требований:

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

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

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

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

Бизнес-правила включают корпоративную политику, законодательные акты, индустриальные стандарты, учетную практику и алгоритмы вычислений.

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

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

Следующим этапом разработки системы является системный анализ, который непосредственно связан с бизнес-моделированием. Которые распределяются на фазы жизненные циклы:

1. Определение и стабилизация требований

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

2. Построение и внедрение

• Уточнение требований.
• Обеспечить выпуск и тестирование требований

Далее на проекте приходит стадия проектирование архитектуры, которая ставит перед собой следующие целы:

• Преобразование требований в проект будущей системы;
• Создание «прозрачной» архитектуры для системы;
• Адаптация проекта к выбранной среде реализации, эффективное ее использование.

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

Распределение по фазам:

1. Начало:

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

2. Проектирование:

• Описание архитектуры.
• Проверка выбранных решений

3.  Построение:

• Надзор за реализацией частей системы
• Внесение дополнений и изменений в архитектуру
• Посредник между командами
• Слежение за выполнением руководств

4. Внедрение:

• Принятие критических решений по крупным дефектам

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

1. Начало

• Создание концептуальных прототипов.

2. Проектирование

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

3. Построение

• Проектирование, реализация, тестирование большей части кода.

4. Внедрение

• Устранение дефектов.

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

1. Миссии тестирования – соответствует целям фазы:

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

2. Начало

• Апробирование идей тестов.
• Настройка инструментов тестирования
• Составление требования, касающихся тестирования.

3. Проектирование

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

4. Построение

• Функциональное тестирование.
• Нефункциональное тестирование (производительность).

5. Внедрение

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

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

Модель – это упрощенное представление объектов и явлений реального мира. Его смысл – это углубленное понимание исследуемую систему. Задачи моделирования [3]:

• Визуализация системы в ее некотором состоянии.
• Определение структуры и поведения системы.
• Получение шаблона для создания системы.
• Документирование принятых решений.

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

Объектный подход – один из ключевых подходов к моделированию. В результате OOA & OOD мы получаем «хороший» проект программной системы, прозрачный, удовлетворяющий требованиям, удобный для тестирования и отладки, коллективной разработки, развиваемый, допускающий повторное использование компонентов.

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

1. IEEE Std 610.12. "IEEE Standard Glossary of Software Engineering Terminology"
2. [Leffingwell&Widrig.2003]-DeanLeffingwell, DonWidrig.ManagingSoftware Requirements: A Use Case Approach. Second Edition. Addison Wesley (ISBN 0- 321-12247-X), 2003
3. [Вигерс, 2003] - Карл И. Вигерс. Разработка требований к программному обеспечению. Издательско-торговый дом "Русская редакция", перевод на русский язык второй редакции книги - Microsoft Corporation (ISBN 5-7502- 0240- 2), 2004. Оригинальное издание на английском языке: Software Requirements. Second Edition. Karl E. Wiegers, Microsoft Press (ISBN 0-7356- 1879-8), 2003.
4. [RUP,2003]-RationalUnifiedProcess.Version2003.06.13[SWEBOK,2004]- Guide to Software Engineering Body of Knowledge (SWEBOK). IEEE Computer Society. 2004.
5. [IEEE 830, 1998] - IEEE Recommended Practice for Software Requirements Specifications. IEEE Std 830-1998.
6. [ГОСТ 34.003,1990] - Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Термины и определения. ГОСТ 34.003-90, Государственный Стандарт Российской Федерации. 1999.Госстандарт России. Москва. 1990.