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