При работе сложных информационно-техни­ческих систем зачастую возникает необходимость обработки разнородной информации, получаемой с помощью различных аппаратных и программных средств [1, 2].

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

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

Опираясь на опыт применения объектно-ори­ентированного программирования (ООП), широко используемого при создании информационных систем, отметим, что существуют понятия класса, который представляет собой спецификацию, описывающую новую форму данных, и объекта, представляющего собой индивидуальную реализацию структуры данных, созданную в соответствии с этой спецификацией [3–5]. Поэтому целесообразно рассмотреть ИТП с точки зрения ООП.

В состав ИТП могут входить как аппаратные, так и программные средства, то есть

СИТП = {HИТП, SИТП},

где СИТП – совокупность средств, составляющих ИТП; HИТП – совокупность аппаратных средств; SИТП – совокупность программных средств.

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

При реализации конкретных ИТП обработки информации необходимо использовать механизмы наследования и полиморфизма с введением дополнительных информационных параметров.

Таким образом, систему обработки данных информации можно представить как множество экземпляров процесса Эiq, то есть

Пq = {Э1q, Э2q, …, Эiq}.

Основными компонентами экземпляра ИТП являются входная информация Iiq, операции преобразования Qiq в виде технических Tiq, програм- мных Piq, организационных Oiq средств и ресурсов, а также цель Ciq (требования, ограничения).

В результате формализации каждый экземпляр ИТП может быть представлен как

Эiq = áIiq, Qiq(Tiq, Piq, Oiq), Ciqñ.

Для каждой совокупности Piq целесообразно создать прототип, то есть раннюю версию ПО обработки. Прототип ПО – частичное, возможное и предварительное воплощение предлагаемого нового продукта. Как известно, прототипы служат трем основным целям [6, 7]:

–      прояснение, формулировка и утверждение требований;

–      исследование альтернативных решений;

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

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

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

Первоначально всем программным модулям приписывается состояние «ожидание разработки». Можно считать, что это состояние – очередь для разработчиков. Модуль не перейдет в состояние «в процессе разработки», пока не будет назначена группа разработчиков. По завершении модуль переходит в состояние «в процессе анализа», где ему назначается группа анализа. Пока назначение не произошло, модуль не может перейти в это состояние. Процесс повторяется снова и снова. Так как модули разрабатываются одновременно разными группами, в одном состоянии могут находиться сразу несколько модулей [7].

Кроме того, создание прототипа позволяет оценить затраты на создание ПО и принять соответствующее управленческое решение [8, 9]. Для оценки затрат целесообразно применить алгоритмическую модель оценки стоимости разработки ПО – COnstructive COst MOdel (COCOMO) [10].

Известно, что модель COCOMO применима к трем классам проектов разработки ПО: органическому, полуразделенному и встроенному.

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

COCOMO состоит из иерархии трех последовательно детализируемых уровней [10]: базового, среднего и детального.

С учетом того, что рассматривается прототип ПО Piq ИТП, необходимо использовать базовый уровень, который позволяет оценить трудоемкость и стоимость разработки ПО как функцию от размера программы, при этом размер выражается в оценочных тысячах строк программного кода. Для обозначения объема программных строк используется единица KLOC (Kilo Lines of Code) [6].

Для базового уровня COCOMO используются следующие уравнения:

где L – трудоемкость (человеко-месяцы); ab, bb, cb, db – коэффициенты модели COCOMO базового уровня, равные соответственно 3,6, 1,2, 2,5, 0,32; T – срок разработки (месяцы); N – число разработчиков (человек).

С помощью метода экспертных оценок и/или метода аналогов можно получить примерные оценки значений KLOC для каждого из Piq соответствующего ИТП и рассчитать значения L, T, N.

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

Литература

1.     Evans E. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2003, 1st. ed., 560 p.

2.     Антонов А.В. Системный анализ: учебник для вузов. М.: Высш. школа, 2008. 3-е изд. 454 с.

3.     Prata S. C++ Primer Plus. Addison-Wesley Professional, 2011, 6th ed., 1200 p.

4.     Weisfeld M. The Object-Oriented Thought Process. Addison-Wesley Professional, 2008, 3rd ed., 336 p.

5.     Arlow J., Neustadt I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design. Addison-Wesley Professional, 2005, 2nd ed., 624 p.

6.     Wiegers K., Beatty J. Software Requirements. Microsoft Press, 2013, 3rd ed., 672 p.

7.     Kossiakoff A., Sweet W.N., Seymour S., Biemer S.M. Systems Engineering Principles and Practice. Wiley-Interscience, 2011, 2nd ed., 560 p.

8.     Вдовин В.М., Суркова Л.Е., Валентинов В.А. Теория систем и системный анализ: учебник. М.: Дашков и К, 2010. 640 с.

9.     Тарасенко Ф.П. Прикладной системный анализ. М.: КНОРУС, 2010. 224 с.

10.  Boehm B.W., Abts C., Brown A.W., Chulani S. Software Cost Estimation with Cocomo II, Prentice Hall Publ., 2000, 544 p.

References

1.  Evans E. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional Publ.,
2003, 1st. ed., 560 p.

2.  Antonov A.V. Sistemny analiz  [System  Analysis]. Textbook. 3rd ed. Мoscow, Vysshaya shkola Publ., 2008, 454 p.
(in Russ.).

3.  Prata S. C++ Primer Plus. 6th ed. Addison-Wesley Professional Publ., 2011, 1200 p.

4.  Weisfeld M. The object-oriented thought process. Addison-Wesley Professional Publ., 3rd ed. 2008, 336 p.

5.  Arlow J., Neustadt I.  UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design.  Addison-Wesley Professional Publ., 2 ed. 2005, 624 p.

6.  Wiegers K., Beatty J. Software Requirements. Microsoft Press, 3rd ed., 2013, 672 p.

7.  Kossiakoff A., Sweet W.N., Seymour S., Biemer S.M.  Systems Engineering Principles and Practice. Wiley-Interscience Publ., 2011, 2nd ed., 560 p.

8.  Vdovin V.M., Surkova L.E., Valentinov V.A. Teoriya system i sistemny analiz  [The  Theory of Systems and  System
Analysis]. Textbook. Мoscow, “Dashkov i К°” Publ., 2010, 640 p. (in Russ.).

9.  Tarasenko F.P.  Prikladnoy sistemny analiz  [Applied  System Analysis]. Moscow, KNORUS Publ., 2010, 224 p.  (in
Russ.).

10.  Boehm B.W., Abts C., Brown A.W., Chulani S. Software Cost Estimation with Cocomo II. Prentice Hall Publ., 2000,
544 p.