50
Стандарт – это нормативный документ, разработанный на основе
консенсуса, утвержденный признанным органом, направленный на
достижение оптимальной степени упорядочения в определенной
области. В стандарте устанавливаются для всеобщего и многократного
использования
общие
принципы,
правила,
характеристики
рекомендательного
характера,
касающиеся
различных
видов
деятельности или их результатов.
Таким образом, стандарты в разработке ПС важны по целому ряду
причин. Основными из них являются:
1.
Стандарты аккумулируют все лучшее из практической
деятельности создания ПС и позволяют избежать повторения прошлых
ошибок.
2.
Стандарты предоставляют необходимую
основу для процесса
обеспечения качества: достаточно контролировать соблюдение
стандартов.
3.
Стандарты позволяют упорядочить процесс разработки, что
делает разработку прозрачной и снижает затраты на обучение
профессиональной деятельности при ротации кадров.
При современном уровне сложности программных систем и в
условиях рыночной конкуренции представляется актуальным задача
создания технологии коллективной разработки программных средств
(ПС), которая будет отражать реалии процесса разработки и
обеспечивать рост уровня производства при соответствующем качестве
создаваемых программных изделий (ПИ). Из-за разнообразия типов ПС
и способов их разработки технология
должна обеспечить механизмы
собственной адаптации и автоматизации. Актуальными являются и
аспекты экономической эффективности и правовой защиты технологии
при ее использовании для создания реальных процессов разработки ПС.
Многие современные исследователи в области процессов
разработки программных средств рассматривают процедуру создания
программ как сущность, включающую три тесно связанный компоненты:
процесс (организацию разработки), коллектив разработчиков и
программное изделие. Приводимые в статьях и литературе описания
процедуры разработки ПИ подробно рассматривают ее организацию
(процесс), игнорируя при этом детальное описание других компонент. Те
модели компонент технологии разработки ПС, которые можно встретить
в современной литературе,
носят в основном описательный, а не
формальный характер.
Потребность в создании сложных программных систем приводит к
необходимости регламентации творческого процесса. И каждая
методология программирования пытается построить процесс разработки
51
таким образом, чтобы минимизировать творческий элемент в случаях
рутинной работы. Иными словами, методологии стремятся сделать так,
чтобы сокращалось число ошибок, чтобы как можно раньше переходить
если не к производству, то хотя бы к тому, что является аналогом
производства при разработке программ. Отсюда попытки разграничить
план и конструкцию программы, спецификации пользовательской
потребности и план, выбор инструментов
для работы программиста и
саму работу. Это же приводит к появлению регламентов и предписаний,
следование которым уменьшает вероятность ошибочных решений.
По существу, любая методология представляет собой набор
регламентов и предписаний. В частности, любая методология
выстраивает свою модель жизненного цикла как основу для этих
соглашений.
Понятие жизненного цикла само по себе от методологий не
зависит. И в «хаотическом» конструировании ранних программных
продуктов, и в современных «жестких» методологиях, и
в так
называемых «облегченных» (lightweight) методологиях можно указать на
жизненный цикл. И хотя форма представления жизненных циклов в
разных случаях различна до неузнаваемости, мы настаиваем на том, что
в основе любых представлений разработки и сопровождения
программных изделий лежат общие процессы, которые в конечном итоге
ведут проекты от их замыслов к удовлетворению потребностей
пользователя. Любая методология предписывает организацию этих
общих процессов. Рассмотрим, как проходит предварительная оценка
сложности разработки программных систем на основе статистических
методов в зависимости от этапов разработки программы.
При использовании интегрированных инструментальных средств у
компаний, разрабатывающих типовые решения (под
эту категорию
попадают так называемые «инхаузеры» – компании, занимающиеся
обслуживанием основного бизнеса) появляется возможность строить
прогнозы сложности программ, основываясь на собранной статистике.
Статистический метод хорошо подходит для решения подобных типовых
задач и практически не подходит для прогноза уникальных проектов. В
случае уникальных проектов применяются иные подходы, обсуждение
которых находится за рамками данного материала.
Типовые задачи падают на отделы разработки из бизнеса, потому
предварительная оценка сложности могла бы сильно упростить задачи
планирования и
управления, тем более что есть накопленная база по
проектам, в которой сохранены не только окончательные результаты, но
и все начальные и промежуточные [7, 18, 20].