Технология программирования
1.Основные понятия и подходы к тп
1.1. Основные этапы развития ТП.
ТП – это совокупность методов и средств, используемых в процессе разработки ПО.
ТП представляет собой набор технологических инструкций, включающих:
Указания последовательности выполняемых технологических операций;
Перечень условий, при которых выполняется та или иная операция;
Описание самих операций, где для каждой операции определены исходные данные, результаты, инструкции, нормативы, стандарты, критерии, методы оценки.
Рис.1.1.
Структура описания технологических
операций.
Кроме набора операций, их последовательности технология также определяет способ описания проектируемой системы (модели, используемые на конкретном этапе разработки). Различают технологии, используемые на конкретных этапах разработки или для решения отдельных задач этих этапов, и технологии, охватывающие несколько этапов или весь процесс разработки. В основе первых обычно лежит ограниченно применяемый метод, в основе вторых – базовый метод, или подход, определяющий совокупность методов на разных этапах разработки, или методологию.
Основные этапы развития программирования как науки:
1). «Стихийное» программирование (до середины 60х гг.).
Отсутствовала сформулированная технология, программирование было искусством. Программы имели простейшую структуру (программы на машинном языке и обрабатываемые ими данные).
Рис.1.2. Структура простейших программ.
Появление Ассемблера. Создание языков программирования высокого уровня. Революционным стало появление в языках средств, позволяющих работать с подпрограммами. В связи с чем были созданы библиотеки.
Типичная программа того времени состояла из основной программы, области глобальных данных и набора подпрограмм.
Рис. 1.3. Структура программ с глобальной областью данных.
Было предложено в подпрограмме размещать локальные данные.
Рис. 1.4. Структура программ, использующих локальные данные.
Сложность разрабатываемого ПО по-прежнему ограничивалась возможностью программиста отслеживать процесс обработки данных, но на другом уровне. Появление средств поддержки программ позволило разрабатывать ПО параллельно несколькими программистами.
В начале 60х гг. возник «кризис программирования»: фирмы, разрабатывающие сложные ПО, срывали сроки завершения проектов. Проект устаревал раньше, чем был готов к внедрению. Увеличилась стоимость и т.д..
Объективно это было вызвано несовершенством технологии программирования:
Стихийно использовалась разработка восходящего подхода и т. Д.
Процесс тестирования и отладки программ занимал более 80% времени разработки.
2). «Структурный» подход к программированию (60е – 70е гг.).
Совокупность рекомендуемых технологических приемов, охватывающих выполнение всех этапов разработки ПО. В его основе лежит декомпозиция сложных систем. С появлением других принципов декомпозиции (объектного, логического и т. д.) данный способ стал называться процедурной декомпозицией.
В отличие от процедурного подхода к декомпозиции, структурный подход требовал представления задачи в виде иерархии подзадач простейшей структуры. Проектирование осуществлялось сверху вниз и подразумевало реализацию общей идеи, обеспечивая проработки интерфейсов подпрограмм. Одновременно вводились ограничения на конструкцию алгоритмов, рекомендовались формальные модели и их описание и специальный метод проектирования алгоритмов – метод пошаговой декомпозиции. Поддержка принципов «структурного» программирования была заложена в основу процедурных языков программирования. Обычно они включали «структурные» операторы передачи управления, поддерживали вложенность подпрограмм, локализацию и ограничения области видимости данных. Дальнейший рост сложности и размеров разрабатываемого ПО потребовал развития структурирования данных, т.е. в языках программирования появилась возможность определения последовательных типов данных. Усилилось стремление разграничивать доступ к глобальным данным программы. В результате появилась технология модульного программирования.
Модульное программирование предполагает выделение группы программ, использующих одни и те же глобальные данные в отдельно компилируемые модули (библиотеки). Связи между модулями осуществляется через специальный интерфейс, а доступ к реализации модуля (телам подпрограмм и некоторым внутренним переменным) запрещен. Эту технологию поддерживают современные версии языков Pascal,C,Ada.
1…n1 – подпрограммы с локальными данными.
Рис. 1.5. Структура программ, состоящих из модулей.
Использование модульного программирования упростило разработку ПО несколькими программистами: каждый мог разрабатывать свои модули независимо, обеспечивая взаимодействие модулей через межмодульный интерфейс. Также модули без изменений могли быть использованы в других разработках.
Буг: «Структурный» подход в сочетании с модульным программированием позволил получать достаточно надежные программы размером <= 100000 операторов». Недостатки модульного программирования: ошибка в интерфейсе при вызове подпрограммы выявляется только при выполнении программы. При увеличении размера программы вырастает сложность межмодульных интерфейсов и с некоторого момента предусмотреть взаимодействие отдельных частей программы становится практически невозможно. Для разработки ПО большого объема было предложено использовать объектный подход.
3). Объектный подход (середина 80-х – конец 90х гг.).
Объектно-ориентированное программирование (ООП) определяется как технология создания сложного ПО, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса. Классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений.
Рис.1.6. Структура программы при ООП.
Развитие технологий программирования, основанных на объектном подходе, позволило решить многие проблемы. Были созданы среды, поддерживающие визуальное программирование. Результатом визуального программирования является заготовка будущей программ, в которую внесены соответствующие коды.
Использование объектного подхода имеет ряд преимуществ, но конкретная реализация в объектно-ориентированных языках (Pascal,C++) имеет недостатки:
Фактически отсутствуют стандарты компоновки двоичных результатов компиляции объектов в единое целое, даже в пределах одного языка программирования, что приводит к необходимости разработки ПО с использованием средств и возможностей одного языка программирования и одного компилятора, а значит требует наличия исходных кодов, используемых библиотек классов.
Изменение реализации одного из программных объектов как минимум связано с перекомпиляцией соответствующего модуля и перекомпоновкой всего ПО, использующего данный объект. Т.о. при использовании этих языков программирования сохраняется зависимость модулей ПО от адресов экспортируемых полей и методов, а также от структуры форматов данных. Эта зависимость объективна, так как модули должны взаимодействовать между собой, обращаясь к ресурсам друг друга. Связи модулей нельзя разорвать, но можно попробовать стандартизировать их взаимодействие, на чем и основан компонентный подход к программированию.
4). Компонентный подход и case-технологии (середина 90х – наше время).
Он предполагает построение ПО из отдельных компонентов, физически отдельно существующих частей ПО, которые взаимодействуют между собой через стандартизированные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространяемые в двоичном виде (без исходных текстов), и использовать в любом языке программирования, поддерживающем соответствующую технологию. В настоящее время рынок объектов стал доступным. Это позволяет создавать программные продукты, хотя бы частично состоящие из повторно используемых частей, т. е. использовать технологию, которая хорошо зарекомендовала себя в области проектирования аппаратуры.
Компонентный подход лежит в основе технологий, разработанных на базе COM, и технологии создания распределенных приложенийCORBA(общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы, различаются особенностями их реализации.
Технология COMфирмыMicrosoftявляется дальнейшим развитием технологииOLE1. ТехнологияCOMопределяет общую парадигму взаимодействия программ любых видов: библиотек, приложений, операционной системы, т. е. позволяет одной части ПО использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах на одном компьютере или на разных компьютерах (Рис. 1.7.). МодификацияCOM, обеспечивающая передачу вызовов между компьютерами, называетсяDCOM(распределеннаяCOM).
Рис. 1.7. Взаимодействие программных компонентов различных типов.
По технологии COMприложение предоставляет свои службы, используя специальные объектыCOM, которые являются экземплярами классовCOM. ОбъектCOM, как и обычный объект, включает поля и методы, но в отличие от обычных объектов, объектCOMможет реализовать несколько интерфейсов, обеспечивающих доступ к его полям и функциям. Это достигается за счет организации отдельной таблицы адресов метода для каждого интерфейса (по типу таблиц виртуальных методов). При этом интерфейс обычно объединяет несколько однотипных функций. Кроме этого классыCOMподдерживают наследование интерфейса, но не поддерживают наследование реализации, т. е. наследуют код метода, хотя при необходимости объект класса потока может вызвать метод родителя. Каждый интерфейс имеет имя, начинающееся с буквыI, и глобальный уникальный идентификаторID. Любой объектCOMобязательно реализует интерфейсIUnknown. На схемах этот интерфейс всегда располагается сверху. Использование его позволяет получить доступ ко всем интерфейсам объекта.
Объект всегда функционирует в составе сервера – динамической библиотеки или исполняемого файла, который обеспечивает функционирование объекта.
Различают три типа серверов:
1). Внутренний сервер.
Реализуется динамическими библиотеками, которые подключаются к приложению клиента и работают в одном с ним адресном пространстве. Это наиболее эффективный сервер и не требует специальных средств.
2). Локальный сервер.
Создается отдельным процессом (модулем .exe), который работает на одном компьютере с клиентом.
3). Удаленный сервер.
Создается процессом, который работает на другом компьютере.
Для обращения к службам клиент должен получить указатель на соответствующий интерфейс. Перед первым обращением к объекту клиент посылает запрос к библиотеке COM, хранящей информацию обо всех зарегистрированных в системе классахCOM-объектов и передает ей имя класса, идентификатор интерфейса и тип сервера. Библиотека запускает необходимый сервер, создает требуемые объекты и возвращает указатели на объекты и интерфейсы. Получив указатели, клиент может вызывать необходимые функции объекта.
Взаимодействие клиента и сервера обеспечивается базовыми механизмами DCOM, поэтому клиенту безразлично местонахождение объекта. При использовании локального или удаленного сервера в адресном пространстве клиента создается так называемыйproxy-объект (заменитель объектаCOM), а в адресном пространстве сервера -COM-заглушка, соответствующая клиентам. Получив задание от клиента, заместитель упаковывает его параметры и, используя службы ОС, передает вызов заглушке. Заглушка распаковывает задание и передает его объектуCOM, результат возвращается клиенту в обратном порядке.
На базе технологии COMиDCOMбыли разработаны компонентные технологии, решающие различные задачи разработки ПО:
- OLE-automation– технология создания программируемых приложений, обеспечивающих программируемый доступ к внутренним службам этих приложений. Вводит понятие диспинтерфейса – специального интерфейса, облегчающего вызов объекта.
- ActiveX– технология, построенная на базеOLE-automation, предназначенная для создания ПО, как сосредоточенного на одном компьютере, так и распределенного в сети. Предполагает использование визуального программирования для создания компонентов – элементов управленияActiveX. Полученные таким образом элементы управления могут устанавливать на компьютер дистанционно с удаленного сервера, причем устанавливаемый код зависит от используемой ОС. Это позволяет применять элементы управленияActiveXв клиентских частях приложенийInternet. Основные преимуществаActiveX:
Быстрое написание программного кода, так как все действия, связанные с организацией взаимодействия сервера и клиента на программное обеспечение COM, программирование сетевых приложений становится похожим на программирование самого компьютера;
Открытость и мобильность. Сертификация технологии передана в OpenGroup, как основа открытого стандарта;
Возможность написания приложений с использованием знакомых приложений, таких как VisualC++,BorlandC++ и т.д. и любых средств разработкиJava;
Большое количество уже существующих бесплатных программных элементов ActiveX, к тому же практически любой программный компонентOLEсовместим с технологиямиActiveXи может применяться без модификаций в сетевых приложениях;
Стандартность. Технология ActiveXоснована на стандартахInternet(TCP/IP,Java,HTML) с одной стороны и стандартах, необходимых для сохранения совместимости (COM,OLE), с другой.
- MTS (MicrosoftTransactionServer) (сервер управления транзакциями) – технология, обеспечивающая безопасность и стабильную работу распределенных приложений при больших объемах передаваемых данных.
- MIDAS (сервер многозвенных распределенных приложений) – технология, организующая доступ к данным разных компьютеров с учетом балансировки нагрузки сети.
Все указанные технологии реализуют компонентный подход, заложенный в COM. С точки зренияCOM, элемент управленияActiveX– это внутренний сервер, поддерживающий технологиюOLE-automation. Для программиста элементActiveX– это «черный ящик», обладающий свойствами, методами и событиями, которые можно использовать, как строительный блок при создании приложений.
- Технология CORBA. Разработана группой компанийOMG(ObjectManagementGroup) (группа внедрения объектных технологий программирования). Она реализует подход аналогичныйCOMна базе объектов и интерфейсовCORBA. Программное ядроCORBAреализовано для всех основных аппаратных и программных платформ, поэтому эту технологию можно использовать для создания распределенного ПО в гетерогенной вычислительной среде. Организация взаимодействия между объектами клиента и сервер вCORBAосуществляется с помощью специального посредникаVisiBrokerи других специальных ПО.
Отличительной особенностью современного этапа развития технологий программирования, кроме изменения подхода, является создание и внедрение автоматизированных технологий разработки и сопровождения ПО (CASE-технологии) (ComputerAddedSoftware/SystemEngineering) (разработка программного обеспечения/ программных систем с использованием компьютерной поддержки). Без средств автоматизации разработка сложного ПО становится трудноосуществимой (память человека не в состоянии фиксировать все детали, необходимые при разработке ПО). Сегодня существуютCASE-технологии, поддерживающие структурный и объектный (в том числе компонентный) подходы к программированию. Появление нового подхода не означает, что теперь все ПО будет создаваться из программных компонентов. Но анализ существующих проблем разработки сложного ПО показывает, что он будет применяться широко.
1.2. Проблемы разработки сложных программных систем
Большинство современных программных систем объективно очень сложны. Эта сложность обусловлена многими причинами, главная из которых логическая сложность решаемых ими задач. Пока вычислительных машин было мало, их возможности были ограничены. ЭВМ применялись в узких областях науки и техники и основном там, где решаемые задачи были хорошо детерминированы и требовали больших вычислений. В настоящее время, когда созданы мощные компьютерные сети, появилась возможность переложить на них решение сложных ресурсоёмких задач. В процесс компьютеризации вовлекаются новые предметные области и усложняются постановки задач для уже освоенных областей.
Дополнительные факторы, увеличивающие сложность разработки программных систем:
1). Сложность форматного определения требований к программным системам.
2). Отсутствие удовлетворительных средств описания поведения дискретных систем с большим числом состояний при недетерминированной последовательности входных воздействий.
3). Коллективная разработка.
4). Необходимость увеличения степени повторяемости кодов.
Сложность определения требований обуславливается двумя факторами:
1). При определении требований необходимо учитывать большое количество различных факторов.
2) Разработчики программных систем не являются специалистами в автоматизируемых предметных областях и наоборот.
Вместе взятые эти факторы существенно увеличивают сложность процесса разработки. Очевидно, что они все напрямую связаны со сложностью объекта разработки программной системы.
1.3 Блочно-иерархический подход к созданию сложных систем
Большинство сложных систем в природе и технике имеет иерархическую внутреннюю структуру. Это связано с тем, что связи элементов сложных систем различны по типу и по силе, что позволяет рассматривать системы как совокупность взаимозависимых подсистем.Внутренние связи элементов таких подсистем сильнее, чем связи между подсистемами. Используя то же различие связей, каждую подсистему можно разделить на подсистемы и т.д. до самого нижнего «элементарного» уровня (выбор уровня, компоненты которого следует считать элементарными, остается за исследователем). На элементарном уровне система состоим из немногих типов подсистем, по-разному скомбинированных и организованных. Иерархии такого типа получили название «целое – часть».
Поведение системы в целом сложнее поведения отдельных частей, из-за более сильных внутренних связей особенности системы в основном обусловлены отношениями между ее частями, а не частями как таковыми.
В природе существует и иерархия «простое – сложное»или иерархия развития (усложнения) систем в процессе эволюции. Здесь любая функционирующая система является результатом развития более простой системы (данный вид иерархии реализуется механизмом наследования ООП).
Программные системы – отражение природных и технических систем – обычно являются иерархическими, т.е. обладают описанными выше свойствами. На этих свойствах иерархических систем строится блочно-иерархический подходк их исследованию или созданию. Этот подход предполагает сначала создавать части таких объектов (блоки, модули), а затем собирать из них сам объект.
Процесс разбиения сложного объекта на сравнительно независимые части называется декомпозицией. При декомпозиции учитывают, что связи между отдельными частями должны быть слабее, чем связи элементов внутри частей. Чтобы из полученных частей можно было собрать разрабатываемый объект, в процессе декомпозиции необходимо определить все виды связей частей между собой.
При создании сложных объектов процесс декомпозиции выполняется многократно: каждый блок декомпозируют на части, пока не получают блоки, которые сравнительно легко разработать. Такой метод разработки получил название пошаговой детализации.
В процессе декомпозиции стараются выделить аналогичные блоки, которые можно было бы разрабатывать на общей основе. Таким образом обеспечивают увеличение степени повторяемости кодов и, соответственно, снижение стоимости разработки.
Результат декомпозиции обычно представляют в виде схемы иерархии, на нижнем уровне которой располагают сравнительно простые блоки, а на верхнем – объект, подлежащий разработке. На каждом иерархическом уровне описания блоков выполняют с определенной точностью детализации,абстрагируясьот несущественных деталей. Следовательно, для каждого уровня используют свои формы документации и свои модели, отражающие сущность процессов, выполняемых каждым блоком. Для объекта в целом формулируют лишь самые общие требования, а блоки нижнего уровня олжны быть специфицированы так, чтобы из них можно было собрать работающий объект.Чем больше блок, тем более абстрактным должно быть его описание.
При соблюдении этого принципа разработчик сохраняет возможность осмысления проекта и может принимать наиболее правильные решения на каждом этапе, что называют локальной оптимизацией.
Примечание. Понятие сложного объекта по мере совершенствования технологий меняется: то что было сложным вчера, не обязательно останется сложным завтра.
Итак, в основе блочно – иерархического подхода лежат декомпозиция и иерархическое упорядочение. Важную роль играют принципы:
непротиворечивость – контроль согласованности элементов между собой;
полнота – контроль на присутствие лишних элементов;
формализация – строгость методического подхода;
повторяемость – необходимость выделения одинаковых блоков для удешевления и ускорения разработки;
локальная оптимизация – оптимизация в пределах уровня иерархии.
Совокупность языков моделей, постановок задач, методов описаний некоторого иерархического уровня называют уровнем проектирования.
Каждый объект в процессе проектирования приходится рассматривать с нескольких сторон. Различные взгляды на объект проектирования называют аспектами проектирования.
Использование блочно-иерархического подхода:
делает возможным создание сложных систем;
упрощает проверку работоспособности системы в целом и отдельных блоков;
обеспечивает возможность модернизации систем, например, замены ненадежных блоков с сохранением их интерфейсов.
Использование блочно-иерархического подхода применительно к программным системам стало возможным только после конкретизации общих положений подхода и внесения некоторых изменений в процесс проектирования. При этом структурный подход учитывает только свойство иерархии «целое–часть», а объектный – использует еще и свойства иерархии «простое-сложное».
1.4. Жизненные циклы, этапы разработки ПО
Жизненный цикл – период от момента появления идеи ПО до завершения его поддержки. Состав процессов ЖЦ регламентируется международным стандартом ISO/IEC12207. Этот стандарт описывает структуру ЖЦ ПО и его процессы. Процесс ЖЦ – это совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Каждый процесс характеризуется определенными задачами, методами их решения, исходными данными, результатами. Структура процессов:
основные процессы: приобретение, поставка, разработка, эксплуатация, сопровождение;
вспомогательные процессы: документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, решение проблем.
организационные процессы: управление, усовершенствование, создание инфраструктуры, обучение.
По стандарту процесс разработки включает действия:
подготовительную работу – выбор модели ЖЦ стандартов, методов, средств разработки, составление плана работ:
анализ требований к системе – определение её функциональных возможностей, пользовательских требований, требований надежности и безопасности к внешним интерфейсам и т.д.
проектирование архитектуры системы – определение состава необходимого оборудования программного обеспечения и операций, выполняемых обслуживающим персоналом.
анализ требований к ПО – определение функциональных возможностей, включая характеристики производительности, среды функционирования компонентов, внешних интерфейсов, спецификации надежности и безопасности, эргономических требований, требований к используемым данным, установке, приемке, пользовательской документации, эксплуатации и сопровождению.
проектирование архитектуры ПО – определение структуры ПО, документирование интерфейсов его компонентов, разработка предварительной версии пользовательской документации, требования к тестам и планы интеграции.
детальное проектирование ПО – подробное описание компонентов ПО и интерфейсов между ними, разработка требований к тестам и плана тестирования ПО.
кодирование и тестирование ПО.
интеграция ПО – сборка программных компонентов
квалификационное тестирование ПО
интеграция системы
квалификационное тестирование системы
установка и приемка ПО.
Эти действия можно сгруппировать, выделив основные этапы разработки ПО.
ГОСТ 19.102-77 ( “стадии разработки”):
постановка задача (стадия “техническое задание”)
анализ требований, разработка, спецификация (стадия “эскизный проект”)
проектирование (“технический проект”)
реализация (“рабочий проект”)
Сопровождение – это процесс создания и внедрения нового продукта.
1.5. Эволюция моделей ЖЦ ПО
Каскадная модель(70-85г.): переход на следующую стадию осуществляется после того, как полностью будут завершены проектные решения предыдущей стадии и получены все исходные данные для следующей стадии.
Рис.1.8.
Достоинства:
получение в конце каждой стадии законченного набора проектной документации, отвечающей требованиям полноты и согласованности.
простота планирования процесса разработки.
Эту схему обычно используют при блочном иерархическом подходе к разработке сложных технических объектов. Но эта схема оказалась применима только к созданию систем, для которых в начале разработки можно точно и полно сформулировать все требования. Реальный процесс разработки носит итерационный характер.
Модели с промежуточным контролем.
Контроль выполняется после завершения каждого этапа, что позволяет вернуться на любой уровень и внести необходимые изменения.
Рис.1.9.
Опасность использования этой схемы – разработка никогда не будет завершена.
Спиральная модель(середина 80-х)
ПО создается не сразу, а итерационно с использованием метода прототипирования. Прототипом называется действующий программный продукт, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО.
На первой итерации обычно проектируют, реализуют и тестируют интерфейс пользователя. На второй добавляют ограниченный набор функций.
Достоинства: начиная с некоторой итерации (где обеспечена определенная функциональная полнота) продукт уже можно предоставлять пользователю, что позволяет:
сокращает время до появления первых версий программного продукта;
заинтересованность большого количества пользователей;
уменьшить вероятность морального устаревания системы.
Основная проблема – это определение моментов перехода на следующие стадии. Для её решения обычно ограничивают сроки прохождения каждой стадии, основываясь на экспертных системах.
1.6. Ускорение разработки ПО. Технология RAD
RAD– быстрая разработка приложений.
Эта технология ориентирована на максимально быстрое получение первых версий разрабатываемого ПО. Она предусматривает выполнение следующих условий:
ведение разработки небольшими группами разработчиков (3-7 человек), каждый из которых реализует отдельные подсистемы проекта
использование итерационного полхода способствует уменьшению времени получения работоспособного прототипа
наличие четкого графика каждого цикла.
Процесс разработки:
анализ и планирование требований: формулирует наиболее приоритетные требования;
проектирование. Используя CASE–средства, детально описывают процессы системы; устанавливают требования разграничения доступа к данным; определяют состав документации. Для наиболее сложных процессов создают частичный прототип (экранную форму и диалог). По результатам анализа процессов определяют количество функциональных точек и принимают решения о количестве подсистем. Функциональная точка в технологииRAD– это любой из следующих функциональных элементов разрабатываемой системы:
а) входной элемент приложения (входной документ или экранная форма);
б) выходной элемент (экранная форма, документ и т.д.);
в) запрос (вопрос – ответ);
г) логический файл (совокупность записей данных, используемых внутри приложения);
д) интерфейс приложения.
Нормы: меньше 1000 функциональных точек - достаточно одного человека;
от 1000-4000 – команда разработчиков (3 – 7 человек);
на каждые 4000 – команда.
По этим нормам разрабатываемую систему делят на подсистемы, слабо связанные по данным и функциям, и точно определяют интерфейсы между различными частями. Использование CASE– средств позволяет избежать неконтролируемого искажения данных.
на этапе реализации выполняют итеративные построения различной системы. Части постепенно интегрируют систему. При подключении каждой части выполняют тестирование. Затем формулируют требования к аппаратным средствам.
на этапе внедрения проводят обучение пользователей и осуществляют переход на новую систему.
Технология RADхорошо зарекомендовала себя для относительно небольших проектов для конкретного заказчика. Эта технология не применима для построения сложных расчетных программ, операционных систем, программ управления сложными объектами в реальном масштабе времени, при создании приложений, от которых зависит безопасность людей.
1.7. Оценка качества процессов создания ПО.
Существуют несколько стандартов, связанных с оценкой качества процессов, которое обеспечивает организация-разработчик.
1). Международные стандарты серии ISO9000 (9000-9004).
2) CMM(CapabilityMaturityModel) (модель совершенствования процессов создания ПО). Эту модель предложилSEI(SoftwareEngineeringInstitute).
3) Рабочая версия международного стандарта ISO/IEC15504. Эта версия более известна под названиемSPICE. (Определение возможностей улучшения процесса создания ПО).
1). Серия стандартов ISO9000: сформулированы необходимые условия для достижения некоторого минимального уровня организации процесса, но не дается никаких рекомендаций по дальнейшему совершенствованию процесса.
2). CMM– это совокупность критериев оценки зрелости организации-разработчика и рецептов улучшения существующих процессов. ВCMMопределяют 5 уровней зрелости организаций-разработчиков:
начальный (initiallevel). Он описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятиях такого уровня не существует стабильных условий для создания качественного ПО. Результат проекта полностью зависит от опыта программиста;
повторяемый (repeating). На предприятии внедрены технологии управления проектами. Существуют стандарты на разрабатываемое ПО и группа обеспечения качества;
определенный (defined). Стандартный процесс создания и сопровождения ПО полностью документирован;
управляемый уровень (managed). В организации устанавливают количественные показатели качества на программные продукты и на процесс в целом.
оптимизирующий (optimizing). Мероприятия по улучшению качества применяются не только к существующим процессам, но и для оценки эффективности новых технологий.