Планирование работ по созданию программных средств для информационных технологий
Липаев В.В.

На базе публикаций и зарубежных стандартов жизненного цикла (ЖЦ) сложных программных средств создан обобщенный перечень 100 работ при разработке, поддержке эксплуатации и сопровождении первой версии критического ПС реального времени. Выделена совокупность работ, обеспечивающих создание таких ПС. Рассмотрены типовые варианты планов разработки более простых ПС разных классов и объема при различной степени применения повторно используемых компонент; - Для этих вариантов выделены перечни работ, которые могут быть использованы при подготовке рабочих планов создания соответствующих типов ПС. Предложено на их основе автоматизировать планирование разработки программ для информационных технологий.

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

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

обобщенные технико-экономические показатели (ТЭП) завершенных разработок ПС и оценки влияния на них различных факторов объекта и среды разработки;

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

реализованные и обобщенные (типовые) перечни выполненных работ и графики проведения разработок в составе жизненного цикла (ЖЦ) различных ПС;

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

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

В [1,2] опубликованы результаты анализа статистических данных о процессах и технико-экономических показателях разработки различных ПС. Отечественные данные [2] о характеристиках 250 проектов общим объемом более 16 млн. команд послужили базой методики и пакета программ для автоматизированного прогнозирования трудоемкости, длительности разработки и числа необходимых специалистов при создании ПС - ПРОТЭП [3]. Этот же пакет позволяет оценивать распределения показателей по основным этапам работ. Таким образом, создана отечественная статистическая база для укрупненного планирования и прогнозирования основных экономических характеристик разработки ПС.

На базе опубликованных моделей жизненного цикла и процессов разработки, поддержки эксплуатации и сопровождения ПС различной сложности и назначения [1, 4-8] ниже представлена обобщенная модель ЖЦ сложных, критических ПС реального времени (прил. 1). „

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

Представленный в прил. 1 ЖЦ ПС можно разделить на две части, существенно различающиеся особенностями процессов, технико-экономическими характеристиками и влияющими на них факторами. В первой части ЖЦ производятся системный анализ, проектирование, разработка, тестирование и испытания ПС (этапы 1-6 в прил. 1). Номенклатура работ, их трудоемкость, длительность и другие характеристики на этих этапах существенно зависят от объекта и среды разработки. Изучение подобных зависимостей для различных ПС позволяет прогнозировать состав и основные характеристики графиков работ для вновь создаваемых версий ПС, поэтому целесообразно выделить представительную выборку вариантов ПС, для которых разработать типовые перечни и графики работ.

Вторая часть ЖЦ, отражающая поддержку эксплуатации и сопровождения ПС (этапы 7 и 8 в прил. 1) относительно слабо связана с характеристиками объекта и среды разработки. Номенклатура работ на этих этапах более или менее стабильна, а их трудоемкость и длительность могут сильно варьироваться и зависят от тиража и массовости применения ПС. Успех ПС у пользователей и на рынке, а также процесс развития версий трудно предсказать, и он не связан непосредственно с параметрами ПС. Определяющими становятся потребительские характеристики и качество ПС, а их особенности с позиции разработчиков отходят на второй план. Вследствие этого в широких пределах изменяется трудоемкость и необходимое число специалистов, поддерживающих эти этапы,что затрудняет обобщение ТЭП различных проектов и прогнозирование на их основе аналогичных характеристик новой разработки. Поэтому графики работ на этих этапах имеют относительный характер общих взаимосвязей работ, которые требуют ручного распределения во времени, индивидуально для каждого проекта. В результате планирование трудоемкости, длительности и числа специалистов для этих этапов приходится производить итерационно на базе накопления опыта и анализа развития конкретных версий ПС.

Приведённые обстоятельства определили целесообразность сосредоточить внимание на планировании процессов первой части (этапы 1-6) ЖЦ ПС. Для этих процессов имеется возможность обобщения ТЭП, перечней и графиков выполнения работ, которые могут служить базой и прототипами для автоматизированного планирования новых проектов ПС. Однако и в этой части ЖЦ ПС различные этапы и частные работы существенно различаются предсказуемостью их трудоемкости, длительности и других ТЭП.

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

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

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

При формировании базового обобщенного варианта важной задачей являлось выделение основных крупных этапов с достаточно завершенными и контролируемыми результатами, а также коррелированных с наиболее популярными моделями ЖЦ ПС [1, 4, 5, 8], поэтому, в частности, управление проектом и интегральные процессы, выделяемые в стандартах ЖЦ ПС [6,7] параллельно всем основным этапам разработки^ прил. 1 объединены с этими этапами.

Номенклатура частных работ внутри этапов сформирована с учетом их более или менее одинакового влияния на процесс создания ПС и его трудоемкость. Этот перечень работ в базовом варианте должен был охватывать практически все остальные варианты. Последовательность частных работ внутри этапов прил. X, в основном соответствует целесообразному и традиционному поряжу их начала. Однако значения их длительностей могут сильно различаться, поэтому при формировании реальных планов работ возможны изменения порядка начала их выполнения вследствие зависимости от завершения предшествующих работ. На этапах проектирования (этапы 2 и 3) и интеграции компонент (этап 5) значительная часть частных работ обусловлена процессами технологической поддержки разработки и гарантий качества. Эти работы целесообразно сгруппировать и упорядочить автономно (подэтапы 2.2,3.2,5.2) в соответствии с логикой их проведения, не связывая непосредственно с процессами разработки ПС (подэтапы 2.1,3.1,5.1).

Рассмотрим основные особенности этапов создания ПС, их технико-экономических показателей и состава частных работ исходного варианта ПС в прил 1. Для новых проектов этап системного анализа является одним из наименее определенных и трудно планируемых. Для этого этапа характерны три крупные группы работ: исследование и разработка концепций; анализ и разработка спецификаций требований; предварительное планирование технологической поддержки разработки ПС. Частные работы в этих группах имеют достаточно определенные взаимосвязи и последовательность, которые позволяют их представить упорядочение во времени. Однако трудоемкость и длительность каждой работы и их суммарные значения для всего этапа можно планировать только в тех случаях, когда имеются близкие прототипы данного проекта с аналогичными функциями. Для этого по завершенным прототипам должны быть собраны и обобщены ТЭП с учетом конкретных особенностей объектов и среды разработки. В результате для этапа системного анализа можно использовать обобщенную структуру и описание работ, которые требуют индивидуальной адаптации ТЭП для каждого конкретного проекта.

После создания концепций и спецификации требований возникает возможность более определенного выбора технологии и планирования процесса разработки ПС. При 1тредварительном и детальном проектировании уточняются и детализируются характеристики объекта и ($реды разработки ПС. Соответственно повышается достоверность исходных данных и графиков выполнения последующих работ. Частные работы на этих двух этапах в некоторой степени повторяются с соответствующей последовательной конкретизацией и уточнением. Вследствие этого при разработке упрощенных проектов ПС ряд работ может объединяться, так же как и эти два этапа в общий этап проектирования [8]. После завершения предварительного и детального проектирования целесообразно корректировать план разработки, оценки его ТЭП и условия контракта.

Далее, на этапе кодирования (программирования) компонент, отрабатываются и отлаживаются тексты программ и описания данных для модулей и функциональных групп (компонент) программ. При этом большое значение имеет использование готовых компонент из ранее разработанных и апробированных версий ПС. Если в базе данных проектирования имеется полный комплект таких компонент, то данный этап разработки практически может быть исключен. При создании информационных систем организационного назначения с использованием стандартизированных баз данных и средств пользовательского интерфейса может отсутствовать необходимость разработки оригинальных программных компонент и остальных работ данного этапа. Применение языков программирования четвертого поколения (4 GL) [8], сборочного программирования и повторно используемых компонент не только сокращает работы этапа кодирования, но может позволять исключить ряд работ этапов системного анализа, предварительного и детального проектирования. Объем таких сокращений зависит от степени архитектурной и функциональной преемственности создаваемой версии ПС с предшествующими апробированными версиями.

На этапах интегрирования (комплексирования) программных и информационных компонент и испытаний завершается создание версии ПС в соответствии со спецификацией требований. Перечень и объем работ на этапах может значительно сокращаться в зависимости от степени повторного использования готовых программных и информационных компонент, а также от апробированности методов и технологических средств разработки предшествующих версий ПС. В этих случаях обязательно сохраняются по тестированию и испытаниям версии ПС, а также по обеспечению гарантий ее качества. Выделение технологических работ и гарантий качества в подзтап 5.2 позволяет их представить как единую последовательность, начинающуюся на этапах проектирования (подэтапы 2.2 и 3.2). Эти работы поддерживают не только процессы интеграции и комплексной отладки, но и подготавливают технологию для всех видов испытаний. При повторной разработке версии ПС или полном заимствовании технологии совокупность этих работ значительно сокращается. Таким образом, набор работ на этом этапе сильно зависит от степени преемственности последовательных версий ПС.

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

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

На этапах создания версий ПС (этапы 1-6) на номенклатуру и ТЭП работ в наибольшей степени влияют следующие факторы [1,2,4]: класс создаваемой версии программного средства:

программы управления объектами или технологическими процессами в реальном времени (сложные, встроенные ПС [1]);

программы обработки больших объемов информации в организационных системах (сложные, не встроенные ПС [1]);

пакеты прикладных программ для решения частных инженерных научных задач (простые ПС);

объем программ, оформляемых как законченный программный продукт (менее 10 тыс. строк или более);

степень использования готовых программных и информационных компонент (менее или более 80 % или полностью из готовых компонент);

предполагаемый тираж версии ПС (единичный или массовый). Некоторые из перечисленных характеристик в значительной степени коррелированы. Это учитывалось для сокращения числа вариантов при формировании представительной выборки типовых перечней работ при создании современных проектов ПС. За основу принят вариант коллективной разработки наиболее сложного, критического ПС реального времени, не имеющего предшественников и прототипов (вариант 1). Для этого варианта в прил. 2 использован полностью перечень работ на этапах 1-6 из при. 1 с некоторым сокращением названий работ.

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

Создание первичных версий более простых ПС представлено вариантами 4,5,7, которые по номенклатуре работ не очень сильно отличаются от варианта 1. При наличии преемственности версий ПС возможно значительное упрощение этапов системного анализа и предварительного проектирования, а также процессов подготовки и обеспечения методами и средствами отладки и гарантии качества (вариант.2). В таких вариантах работы концентрируются на этапах детального проектирования, интеграции и испытаний версии ПС.

Еще большее сокращение объема работ, особенно по трудоемкости, происходит, когда имеется полный комплект готовых апробированных программных и информационных компонет (вариант 3 и 6). В этих вариантах исключается этап кодирования и отладки модулей и функциональных групп программ и полностью реализуется сборочное программирование. В предельном варианте 9 разработка версии ПС может быть сведена к созданию спецификаций требований, интеграции необходимого набора компонент, тестированию, испытаниям и документированию соответствующей версии ПС. Подобные варианты типовых графиков работ получают все большее распространение и при их конкретизации возможно дальнейшее сокращение номенклатуры необходимых работ и упрощение графика. Тем не менее и в этих случаях формализация графика может способствовать упорядочению работ, а также снижению их трудоемкости и длительности. Для них характерно менее полное документирование при разработке, относительно короткий ЖЦ и малый тираж ПС. Некоторое сокращение таких работ возможно для малотиражных ПС с редко меняющимися версиями. Для версий ПС, приобретающих широкое распространение, по мере увеличения тиража возрастает детализация работ, углубляется их содержание, а главное, увеличивается трудоемкость каждой. В прил. 2. не заполнен столбец варианта 10, который может быть использован читателем для создаваемого им варианта ПС.

Вариант 1. Первая версия сложного критического ПС реального времени объемом порядка 100 тыс. строк текста или более. Готовые программные компоненты практически отсутствуют, тираж десятки экземпляров, длительность жизни ПС может быть более 10 лет, смена версий через 1-3 года.

Вариант 2. Очередная версия сложного, критического ПС реального времени объемом порядка 100 тыс. строк текста или более. Готовые программные компоненты составляют более 80 % объема, тираж десятки экземпляров, смена версий через 1-3 года.

Вариант 3. Очередная версия сложного, критического ПС реального времени объемом порядка 100 тыс. строк текста или более. Готовые апробированные программные компоненты имеются полностью, смена версий через 1—3 года.

Вариант 4. Первая версия ПС реального времени объемом менее 10 тыс. строк текста. Готовые программные компоненты практически отсутствуют, тираж сотни экземпляров, длительность жизни ПС более 10 лет, смена версий через 1-3 года.

Вариант 5. Первая версия сложного ПС обработки информации в организационной системе объемом порядка 100 тыс. строк или более. Готовые программные и информационные компоненты составляют более 80 % объема, тираж - десятки экземпляров, смена версий через 1-3 года.

Вариант 6. Очередная версия сложного ПС обработки информации в организационной системе. Готовые программные компоненты имеются полностью, информационные компоненты на 80 % номенклатуры, тираж десятки экземпляров, смена версий через 1-3 года.

Вариант 7. Первая версия пакета прикладных программ для решения частных инженерных или научных задач объемом около 100 тыс. строк текста. Готовые программные и информационные компоненты более 50 % объема, тираж - единицы экземпляров.

Вариант 8. Первая версия пакета прикладных программ для решения частных инженерных или научных задач объемом около 10 тыс. строк текста. Готовые программные и информационные компоненты практически отсутствуют, тираж -единичный, версии маловероятны.

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

При детальном учете характеристик объекта и среды разработки каждый из приведенных вариантов может значительно изменяться по трудоемкости и длительности разработки ПС. Ориентиром различия их сложности, в некоторой степени, может служить суммарное число частных работ в выделенных вариантах (последняя строка прил. 2). Это число для предельных вариантов 1 и 9 различается почти в пять раз, однако для первых версий ПС (варианты 1, 4, 5, 7) менее чем в полтора раза. Наибольшим разнообразием работ для варианта 1 выделяются этапы системного анализа (20 работ), предварительного (22) и детального (15) проектирования, а также интеграции, комплексной отладки и предварительных испытаний ПС (18). Этапы кодирования и отладки компонент (8), а также испытаний ПС (7) функционально проще по существу (но не всегда по суммарной трудоемкости), что отразилось на сокращении числа наименований работ.

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

ЛИТЕРАТУРА

1. Боэм Б. У. Инженерное проектирование программного обеспечения // Пер. с англ. Под ред. А. А. Красилова. М.: Радио и связь.1985.512 с

2. Липаев В. В., Потапов А. И. Оценка затрат на разработку программных средств. М.: Финансы и статистика. 1988.224 с

3. Липаев В. В., Гуляев Н. Б. Методы и средства автоматизации прогнозирования гехнико-экономических показателей разработки сложных программных комплексов. Программные продукты и системы. 1990. № 1. С. 69—75.

4. Гантер Р. Методы управления проектированием программного обеспечения. Пер. с англ. / Под ред. В. К. Масловского. М.: мир, 1981.

5. Boehm В. W. Understanding and controlling software cost Proceedings IFIP Congress 1986. North Holland, 1986. P. 703—714.

1. ISO/IEC JTC1/SC7 К 801. ISO Standard for software life-cycle process (Project 7.21). 1990.
2. IEEE STD P1074/D3X. IEEE Standard for software life-cycle process (Project). 1989.
3. Stradis. Product description McDonnell Douglas Corporation. 1990.

Обобщенный перечень работ жизненного цикла сложных, критических ПС

1. Системный анализ ПС

1.1. Исследование и определение концепции ПС

1.1.1 Определение целей, идей и потребностей новой или модифицированной версии ПС.

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

1.1.3. Исследование реализуемости, моделирование и аналитическое обоснование методов и решений при требуемом качестве и имеющихся ограничениях ресурсов.

1.1.4. Анализ рынка, технических и рекламных материалов о подобных ПС.

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

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

1.2. Анализ и разработка спецификации требований на ПС

1.2.1. Формализация функций, условий внешней среды, требований к характеристикам и качеству решения задач.

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

1.2.3. Формирование предварительной спецификации требований к функциональным и рабочим характеристикам ПС.

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

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

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

1.2.7. Подготовка и заключение контракта на разработку версии программного средства.

1.3. Предварительное планирование технологической поддержки разработки ПС

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

1.3.2. Оценка и подготовка к приобретению готовых операционных систем, пакетов прикладных программ и средств автоматизации разработки ПС.

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

1.3.4. Распределение ресурсов и бюджета на функциональные компоненты проекта и субконтракты.

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

1.3.6. Предварительное определение субподрядчиков, их функций и задач по реализации и обеспечению разработки ПС.

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

2. Предварительное (эскизное) проектирование версии ПС

2.1. Процессы предварительного проектирования версии программного средства

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

2.1.2. Анализ характеристик объектов внешней среды и взаимодействия с потенциальными пользователями при использовании разработанного ПС.

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

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

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

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

2.1.7. Проектирование структуры и объемов информационных файлов и их размещение в базе данных ПС.

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

2.1.9. Исследование математической модели системы и ПС, уточнение их характеристик и спецификации требований.

2.1.10. Разработка или выбор методов и средств защиты информации и ПС от несанкционированного доступа.

2.1.11. Разработка предварительного руководства для пользователей и обслуживания проекта ПС.

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

2.1.13. Уточнение объема и характеристик ПС, оценка технико-экономических показателей и графика разработки ПС.

2.1.14. Согласование с заказчиком предварительного (эскизного) проекта ПС и его технико-экономических показателей, уточнение условий контракта.




2.2. Планирование и обеспечение технологической поддержки и гарантий качества программного средства


2.21. Приобретение или разработка и освоение технологии, среды проектирования, средств автоматизации, состава и форм отчетных документов об объектах и процессах разработки

2.2.2. Формирование базы данных проектирования, концептуальное, логическое и физическое распределение информационных и программных объектов проекта.

2.2.3. Подготовка руководства для детального проектирования, .программирования и отладки ПС, согласование словарей понятий и идентификаторов.

2.2.4. Адаптация технологии и используемых средств автоматизации к условиям разработки конкретной версии TIC.

2.2.5. Планирование отладки компонент и обеспечения средствами автоматизации тестирования

2.2.6. Разработка системы показателей качества и методов их измерения для программных компонент и ПС в целом.

2.2.7 Планирование обеспечения гарантий качества и его контроля, поэтапного документирования качества компонент и ПС в целом.

2.2.8. Уточнение плана проектирования, распределения бюджета и специалистов, оценка риска.

3.Детальное (техническое) проектирование версии ПС

3.1. Проданы детального проектирования версии программного средства

3.1.1.Разработка спецификаций требований на функциональные группы программ и модули.

3. 1.2. Формализация межмодульного интерфейса программ и с базой данных информационных компонент ПС.

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

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

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

3.1.6. Разработка детального проекта ПС в соответствии со спецификацией, стандартами и требованиями заказчика.

3.1.7. Документирование детального проекта и предъявление его заказчику, уточнение спецификаций требований и условий контракта.

3.2. Обеспечение технологической поддержки и гарантий качества компонент и программного средства

3.2.1. Уточнение и утверждение руководства по применению технологии, средств автоматизации и стандартов при разработке компонент ПС.

3.2.2. Разработка руководства по контролю, обеспечению качества и надежности функционирования программного средства.

3.2.3. Предварительное планирование интегрирования (комплексирования) программных и информационных компонент и управления конфигурацией ПС.

3.2.4. Предварительное планирование обеспечения средствами автоматизации имитации внешней среды, комплексной отладки и испытаний ПС.

3.2.5. Организация взаимодействия с независимыми организациями по тестированию и сертификации ПС.

3.2.6. Определение методов и средств автоматизации обучения пользователей ПС.


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

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

4. Кодирование (программирование) и отладка компонент

1. Разработка исходных текстов программных модулей, функциональных компонент и описаний данных в соответствии со спецификациями требований, методиками и стандартами.
2. Трансляция исходных текстов и устранение синтаксических и семантических ошибок.
3. Планирование отладки модулей и компонент, подготовка тестовых данных и имитаторов для генерации тестов.
4. Отладка модулей и компонент, устранение ошибок, корректировка текстов программ и описаний данных.

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

6. Испытания модулей и компонент, их аттестация и подготовка для многократного использования.

7. Контроль процесса разработки компонент и выполнения рабочего графика.

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

5.1. Процессы интеграции, комплексной отладки и предварительных испытаний версии программного средства

1. Загрузка базы данных ПС типовыми исходными данными и тестами.
2. Интеграция компонент, тестирование и определение характеристик качества программ решения основных функциональных задач ПС.

3. Интеграция программ решения основных функциональных задач в версию ПС.

4. Тестирование и определение характеристик версии ПС в имитированной внешней среде.

5. Интеграция ПС с аппаратными средствами в реальной операционной и внешней среде

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

7. Квалификационное тестирование, предварительные испытания и определение всех функциональных и технических характеристик ПС в реальной внешней среде.

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

9. Разработка комплекта эксплуатационной документации для пользователей.

5

10. Документирование результатов предварительных испытаний,
описаний и характеристик ПС для предъявления заказчику на приемо-
сдаточные испытания.

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

3. Разработка и аттестация средств автоматизации квалификационного тестирования ПС и обработки результатов отладки.

4. Планирование интеграции ПС с аппаратными средствами системы в реальной операционной и внешней среде.

5. Планирование тестирования ПС и системы в реальной операционной и внешней среде.

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

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

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

6. Испытания и документирование версии программного средства

1. Разработка программы, методик и средства обеспечения приемосдаточных испытаний системы и/или ПС совместно с заказчиком.
2. Адаптация ПС на параметры внешней среды и условия испытаний у заказчика.

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

4. Проведение сертификации или аттестации системы и/или ПС на соответствие спецификации требований и эксплуатационной документации.

5. Документирование результатов приемосдаточных испытаний заказчиком системы и/или ПС и оформление акта о выполнении контракта.

6. Передача разработчиком и приемка заказчиком завершающей спецификации требований, комплекта документации пользователей, системы и/или ПС в соответствии с условиями контракта.

7. Официальное завершение разработки, закрытие контракта заказчиком и окончательный расчет с разработчиком.

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

1. Производство, реклама и маркетинг версии программного средства.
2. Обеспечение технической помощи, обучение и консультации пользователей в процессе эксплуатации ПС.

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

4. Информирование пользователей о частных изменениях в эксплуатируемой версии ПС

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

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

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

8. Сопровождение версий программного средства

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

3. Учет состояний конфигурации ПС, подготовка и накопление отчетов о текущем состоянии и изменениях версий ПС.

4. Реализация модификации и создание очередной версии ПС - корректировка программ, данных и интерфейсов, разработка и интеграция необходимых компонент, отладка и испытания новой версии ПС - полное или частичное повторение этапов 1-6.

5. Приемка заказчиком, установка, настройка, испытания и передача на эксплуатацию новой версии ПС.

_______________________________________
В. В. Липаев - д-р техн. наук, профессор

---

&copy Информационное общество, 1991, вып. 4, с. 38-54.