1 Технология программирования Системное и прикладное программное обеспечение Малышенко Владислав Викторович. - презентация

1 1 Технология программирования Системное и прикладное программное обеспечение Малышенко Владислав Викторович

2 2 Ваши подходы к написанию программ ?

3 3 Технология программирования. Основные понятия и подходы 1. Технология программирования и основные этапы ее развития 2. Проблемы разработки сложных программных систем 3. Блочно-иерархический подход к созданию сложных систем 4. Жизненный цикл и этапы разработки программного обеспечения 5. Эволюция моделей жизненного цикла программного обеспечения 6. Ускорение разработки программного обеспечения. Технология RAD 7. Оценка качества процессов создания программного обеспечения

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

5 5 Структура описания технологической операции Технологическая операция Методические материалы, инструкции, нормативы и стандарты, критерии оценки результатов Исходные данные в стандартном представлении (документы, рабочие материалы, результаты предыдущей операции) Результаты в стандартном представлении Исполнители, программные и технические средства

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

7 7 Первый этап – «стихийное» программирование Этот этап охватывает период от момента появления первых вычислительных машин до середины 60-х годов XX в. В этот период практически отсутствовали сформулированные технологии, и программирование фактически было искусством. Первые программы имели простейшую структуру. Они состояли из собственно программы на машинном языке и обрабатываемых ею данных.

8 8 Первый этап – «стихийное» программирование (2) Сложность программ в машинных кодах ограничивалась способностью программиста одновременно мысленно отслеживать последовательность выполняемых операций и местонахождение данных при программировании. Появление ассемблеров позволило вместо двоичных или 16-ричных кодов использовать символические имена данных и мнемоники кодов операций. В результате программы стали более «читаемыми».

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

10 10 Первый этап – «стихийное» программирование (3) (Идея написания подпрограмм появилась гораздо раньше, но отсутствие средств поддержки в первых языковых средствах существенно снижало эффективность их применения.) Подпрограммы можно было сохранять и использовать в других программах. В результате были созданы огромные библиотеки расчетных и служебных подпрограмм, которые по мере надобности вызывались из разрабатываемой программы. Типичная программа того времени состояла из основной программы, области глобальных данных и набора подпрограмм (в основном библиотечных), выполняющих обработку всех данных или их части.

11 11 Архитектура программы с глобальной областью данных Революционным было появление в языках средств, позволяющих оперировать подпрограммами. Данные Программа 12…n

12 12 Архитектура подпрограмм с локальными данными Архитектура программы, использующей подпрограммы с локальными данными. Данные Программа 12n Данные

13 13 «Стихийное» программирование. Недостатки 1. Сложность разрабатываемого программного обеспечения при использовании подпрограмм с локальными данными по- прежнему ограничивалась возможностью программиста отслеживать процессы обработки данных, но уже на новом уровне. Однако появление средств поддержки подпрограмм позволило осуществлять разработку программного обеспечения нескольким программистам параллельно. 2. В начале 60-х годов XX в. разразился «кризис программирования». Он выражался в том, что фирмы, взявшиеся за разработку сложного программного обеспечения, такого, как операционные системы, срывали все сроки завершения проектов. 3. Проект устаревал раньше, чем был готов к внедрению, увеличивалась его стоимость, и в результате многие проекты так никогда и не были завершены.

14 14 «Стихийное» программирование. Недостатки (2) 4. Объективно все это было вызвано несовершенством технологии программирования. 5. Разработка «снизу-вверх» - подход, при котором вначале проектировали и реализовывали сравнительно простые подпрограммы, из которых затем пытались построить сложную программу. 6. В отсутствии четких моделей описания подпрограмм и методов их проектирования создание каждой подпрограммы превращалось в непростую задачу, интерфейсы подпрограмм получались сложными, и при сборке программного продукта выявлялось большое количество ошибок согласования. 7. Исправление таких ошибок, как правило, требовало серьезного изменения уже разработанных подпрограмм, что еще более осложняло ситуацию, так как при этом в программу часто вносились новые ошибки, которые также необходимо было исправлять В конечном итоге процесс тестирования и отладки программ занимал более 80% времени разработки, если вообще когда- нибудь заканчивался.

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

16 16 Второй этап – структурный подход (2) В отличие от используемого ранее процедурного подхода к декомпозиции, структурный подход требовал представления задачи в виде иерархии подзадач простейшей структуры. Проектирование, таким образом, осуществлялось «сверху вниз» и подразумевало реализацию общей идеи, обеспечивая проработку интерфейсов подпрограмм. Одновременно вводились ограничения на конструкции алгоритмов, рекомендовались формальные модели их описания, а также специальный метод проектирования алгоритмов - метод пошаговой детализации.

17 17 Второй этап – структурный подход (3) Поддержка принципов структурного программирования была заложена в основу так называемых процедурных языков программирования. Они включали основные «структурные» операторы передачи управления, поддерживали вложение подпрограмм, локализацию и ограничение области «видимости» данных. (PL/1, ALGOL-68, Pascal, С) Одновременно со структурным программированием появилось огромное количество языков, базирующихся на других концепциях, но большинство из них не выдержало конкуренции.

18 18 Второй этап – структурный подход (4) Дальнейший рост сложности и размеров разрабатываемого программного обеспечения потребовал развития структурирования данных. Как следствие этого в языках появляется возможность определения пользовательских типов данных. Одновременно усилилось стремление разграничить доступ к глобальным данным программы, чтобы уменьшить количество ошибок, возникающих при работе с глобальными данными. В результате появилась и начала развиваться технология модульного программирования.

19 19 Архитектура программы, состоящей из модулей Глобальные данные Основная программа Модуль 1 1 Данные n1n1 Модуль k 1 Данные nknk

20 20 Модульного программирование Модульное программирование предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные в отдельно компилируемые модули, например, модуль графических ресурсов, модуль подпрограмм вывода на принтер. Связи между модулями при использовании данной технологии осуществляются через специальный интерфейс, в то время как доступ к реализации модуля запрещен. Эту технологию поддерживают современные версии языков Pascal и С (C++), языки Ада и Modula.

21 21 Модульного программирование Использование модульного программирования существенно упростило разработку программного обеспечения несколькими программистами. Теперь каждый из них мог разрабатывать свои модули независимо, обеспечивая взаимодействие модулей через специально оговоренные межмодульные интерфейсы. Кроме того, модули в дальнейшем без изменений можно было использовать в других разработках, что повысило производительность труда программистов.

22 22 Третий этап – объектный подход к программированию Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа, а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений.

23 23 Третий этап – объектный подход к программированию Объектная структура программы впервые была использована в языке имитационного моделирования сложных систем Simula, появившемся еще в 60-х годах XX в. Естественный для языков моделирования способ представления программы получил развитие в другом специализированном языке моделирования - языке Smalltalk (70-е годы XX в.), а затем был использован в новых версиях универсальных языков программирования, таких, как Pascal, C++, Modula, Java.

24 24 Третий этап – объектный подход к программированию Основным достоинством объектно-ориентированного программирования по сравнению с модульным программированием является «более естественная» декомпозиция программного обеспечения, которая существенно облегчает его разработку. Это приводит к более полной локализации данных и интегрированию их с подпрограммами обработки, что позволяет вести практически независимую разработку отдельных частей программы. Кроме этого, объектный подход предлагает новые способы организации программ, основанные на механизмах наследования, полиморфизма, композиции, наполнения. В результате существенно увеличивается показатель повторного использования кодов и появляется возможность создания библиотек классов для различных применений.

25 25 Визуальное программирование Бурное развитие технологий программирования, основанных на объектном подходе, позволило решить многие проблемы. Так были созданы среды, поддерживающие визуальное программирование, например, Delphi, C++ Builder, Visual C++ и т. д. При использовании визуальной среды у программиста появляется возможность проектировать некоторую часть, например, интерфейсы будущего продукта, с применением визуальных средств добавления и настройки специальных библиотечных компонентов.

26 26 Объектного подход: недостатки фактически отсутствуют стандарты компоновки двоичных результатов компиляции объектов в единое целое даже в пределах одного языка программирования: компоновка объектов, полученных разными компиляторами C++ в лучшем случае проблематична, что приводит к необходимости разработки программного обеспечения с использованием средств и возможностей одного языка программирования высокого уровня и одного компилятора, а значит, требует одного языка программирования высокого уровня и одного компилятора, а значит, требует наличия исходных кодов используемых библиотек классов; изменение реализации одного из программных объектов, как минимум, связано с перекомпиляцией соответствующего модуля и перекомпоновкой всего программного обеспечения, использующего данный объект.

27 27 Четвертый этап - компонентный подход и CASE-технологии Компонентный подход предполагает построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы.

28 28 Четвертый этап - компонентный подход и CASE-технологии В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию. Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model - компонентная модель объектов), и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture - общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы и различаются лишь особенностями их реализации.

29 29 Взаимодействие программных компонентов различных типов Объект Компьютер 1 Компьютер 2 Приложение 1 Приложение 2Приложение 3 Операционная система

30 30 Взаимодействие программных компонентов Технология СОМ фирмы Microsoft является развитием технологии OLE I (Object Linking and Embedding - связывание и внедрение объектов), которая использовалась в ранних версиях Windows для создания составных документов. Технология СОМ определяет общую парадигму взаимодействия программ любых типов: библиотек, приложений, операционной системы, т. е. позволяет одной части программного обеспечения использовать функции в разных процессах на одном компьютере или на разных компьютерах. Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM - распределенная СОМ).

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

32 32 CASE-технология Отличительной особенностью современного этапа развития технологии программирования, кроме изменения подхода, является создание и внедрение автоматизированных технологий разработки и сопровождения программного обеспечения, которые были названы CASE- технологиями (Computer-Aided Software/System Engineering разработка программного обеспечения, программных систем с использованием компьютерной поддержки).

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

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

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

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

37 37 Блочно-иерархический подход к созданию сложных систем Каждую подсистему разделить на подсистемы и т. д. до самого нижнего «элементарного» уровня. На элементарном уровне система, состоит из немногих типов подсистем, по-разному скомбинированных и организованных. Иерархии такого типа получили название «целое-часть». Поведение системы в целом обычно оказывается сложнее поведения отдельных частей. В природе существует еще один вид иерархии - иерархия «простое-сложное» или иерархия развития (усложнения) систем в процессе эволюции.

38 38 Блочно-иерархический подход к созданию сложных систем Процесс разбиения сложного объекта на сравнительно независимые части получил название декомпозиции. При создании очень сложных объектов процесс декомпозиции выполняется многократно: каждый блок, в свою очередь, декомпозируют на части пока не получают блоки, которые сравнительно легко разработать. Данный метод разработки получил название пошаговой детализации. Результат декомпозиции обычно представляют в виде схемы иерархии, на нижнем уровне которой располагают сравнительно простые блоки, а на верхнем - объект, подлежащий разработке.

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

40 40 Соотношение абстрактного и конкретного в описании блоков Объект Блок 2Блок 1Блок n Блок 1.1Блок 1.k 1 Блок 2.1Блок 2.k 2 Блок n.1Блок n.k n Уровень 0 Уровень 1 Уровень 2 Конкретизация Абстракция

41 41 Часть II. Жизненный цикл

42 42 Жизненный цикл и этапы разработки программного обеспечения Жизненным циклом программного обеспечения называют период от момента появления идеи создания некоторого программного обеспечения до момента завершения его поддержки фирмой- разработчиком или фирмой, выполнявшей сопровождение. Состав процессов жизненного цикла регламентируется международным стандартом ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes» («Информационные технологии - Процессы жизненного цикла программного обеспечения»).

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

44 44 Структура процессов жизненного цикла программного обеспечения Основные процессы Организационные процессы Вспомогательные процессы Приобретение Поставка Разработка Эксплуатация Сопровождение Управление Усовершенствование Инфраструктура Обучение Документирование Управление конфигурацией Обеспечение качества Верификация Аттестация Совместная оценка Аудит Решение проблем

45 45 Процесс разработки включает следующие действия: подготовительную работу; анализ требовании к системе; проектирование архитектуры системы; анализ требований к программному обеспечению; проектирование архитектуры программного обеспечения; детальное проектирование программного обеспечения; кодирование и тестирование программного обеспечения;

46 46 Процесс разработки включает следующие действия: интеграцию программного обеспечения; квалификационное тестирование программного обеспечения; интеграцию системы; квалификационное тестирование системы; установку программного обеспечения; приемку программного обеспечения.

47 47 Основные этапы разработки программного обеспечения (ГОСТ ) постановка задачи (стадия «Техническое задание»); анализ требований и разработка спецификаций (стадия «Эскизный проект»); проектирование (стадия «Технический проект»); реализация (стадия «Рабочий проект»).

48 48 Модели жизненного цикла программного обеспечения

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

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

51 51 Каскадная схема разработки программного обеспечения Постановка задачи Анализ Проектирование Реализация Модификация

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

53 53 Каскадная схема с промежуточным контролем Постановка задачи Анализ Проектирование Реализация Модификация

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

55 55 Спиральная модель Для преодоления перечисленных проблем в середине 80-х годов XX в, была предложена спиральная схема. В соответствии с данной схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования, базирующегося на создании прототипов. Именно появление прототипирования привело к тому, что процесс модификации программного обеспечения перестал восприниматься, как «необходимое зло», а стал восприниматься как отдельный важный процесс. Прототипом называют действующий программный продукт, реализующий отдельные функции и внешние интерфейсы разрабатываемого программного обеспечения.

56 56 Спиральная модель

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

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

59 59 Использовании CASE-технологий. CASE-технологии представляют собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных программных систем, основанных как на структурном, так и на объектном подходах, которые поддерживаются комплексом взаимосвязанных средств автоматизации. В основе любой CASE-технологии лежит парадигма/методология/метод/нотация/средство. Методология строится на базе некоторого подхода и определяет шаги работы, их последовательность, а также правила распределения и назначения методов. Метод определяет способ достижения той или иной цели - выполнение шага работы.

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

61 61 Использовании CASE-технологий. Виды: CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (CASE-I); CASE-средства генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла разработки программного обеспечения (CASE-II).

62 62 Автоматизированные современные CASE-средства обеспечивают автоматизированный контроль совместимости спецификаций проекта; уменьшают время создания прототипа системы; ускоряют процесс проектирования и разработки; автоматизируют формирование проектной документации для всех этапов жизненного цикла в соответствии с современными стандартами; частично генерируют коды программ для различных платформ разработки; поддерживают технологии повторного использования компонентов системы; обеспечивают возможность восстановления проектной документации по имеющимся исходным кодам.

63 63 Автоматизированные современные CASE-средства (2) Использование CASE-средств позволяет существенно снизить трудозатраты на разработку сложного программного обеспечения в основном за счет автоматизации процессов документирования и контроля. Однако следует иметь в виду, что современные CASE- средства дороги, а их использование требует более высокой квалификации разработчиков. Следовательно, их имеет смысл использовать в сложных проектах, причем, чем сложнее разрабатываемое программное обеспечение, тем больше выигрыш от использования CASE-технологий. На сегодняшний день практически все промышленно производимое сложное программное обеспечение разрабатывается с использованием CASE-средств.

64 64 Качественные изменения процесса разработки программного обеспечения

65 65 Качественные изменения процесса разработки программного обеспечения

66 66 Ускорение разработки программного обеспечения Современная технологии проектирования, разработки и сопровождения программного обеспечения, должна отвечать следующим требованиям: поддержка полного жизненного цикла программного обеспечения; гарантированное достижение целей разработки с заданным качеством и в установленное время; возможность выполнения крупных проектов в виде подсистем, разрабатываемых группами исполнителей ограниченной численности (3-7 человек) с последующей интеграцией составных частей, и координации ведения общего проекта;

67 67 Ускорение разработки программного обеспечения минимальное время получения работоспособной системы; возможность управления конфигурацией проекта, ведения версий проекта и автоматического выпуска проектной документации по каждой версии; независимость выполняемых проектных решений от средств реализации (СУБД, операционных систем, языков и систем программирования); поддержка комплексом согласованных CASE- средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях жизненного цикла.

68 68 технология RAD (Rapid Application Development – Быстрая разработка приложений). Эта технология ориентирована, как следует из названия, на максимально быстрое получение первых версий разрабатываемого программного обеспечения. Она предусматривает выполнение следующих условий: ведение разработки небольшими группами разработчиков (3-7 человек), каждая из которых проектирует и реализует отдельные подсистемы проекта - позволяет улучшить управляемость проекта; использование итерационного подхода способствует уменьшению времени получения работоспособного прототипа; наличие четко проработанного графика цикла, рассчитанного не более чем на три месяца, существенно увеличивает эффективность работы.

69 69 Технология RAD Процесс разработки при этом делится на следующие этапы: Анализ; Планирование требований пользователей; Проектирование; Реализация; Внедрение.

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

71 71 Стандарты качества международные стандарты серии ISO 9000 (ISO ISO 9004); СММ - Capability Maturity Model - модель зрелости (совершенствования) процессов создания программного обеспечения, предложенная SEI (Software Engineering Institute – институт программирования при университете Карнеги-Меллон); рабочая версия международного стандарта ISO/IEC 15504: Information Technology – Software Process Assessment; эта версия более известна под названием SPICE - (Software Process Improvement and Capability dEtermination - определение возможностей и улучшение процесса создания программного обеспечения).

72 72 Серия стандартов ISO 9000 В серии ISO 9000 сформулированы необходимые условия для достижения некоторого минимального уровня организации процесса, но не дается никаких рекомендаций по дальнейшему совершенствованию процессов.

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

74 74 СММ. Начальный уровень (initial level) На предприятии такого уровня организации не существует стабильных условий для создания качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов. Уход менеджеров или программистов с предприятия резко снижает качество производимых программных продуктов В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.

75 75 СММ. Повторяемый уровень (repeatable level) На предприятии внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение и специальная группа обеспечения качества. В случае необходимости организация может взаимодействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень.

76 76 СММ. Определенный уровень (defined level) Характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения полностью документирован. В процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа. Наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от качеств конкретных разработчиков, и процесс не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.

77 77 СММ. Управляемый уровень (managed level) В организации устанавливаются количественные показатели качества, как на программные продукты, так и на процесс в целом. Более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. Осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях.

78 78 СММ. Оптимизирующий уровень (optimizing level) Характеризуется улучшением существующих процессов и оценкой эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. Улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Ведутся работы по уменьшению стоимости разработки программного обеспечения.

79 79 Сертификация СММ Сертификационная оценка соответствия всех ключевых областей проводится по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов.

80 80 Сертификация СММ Оценка ключевой области осуществляется по следующим показателям: заинтересованность руководства в данной области; насколько широко данная область применяется в организации; успешность использования данной области на практике.

81 81 Стандарт SPICE Стандарт SPICE унаследовал многие черты более ранних стандартов (ISO 9001 и СММ). Больше всего SPICE напоминает СММ. Основной задачей организации является постоянное улучшение процесса разработки программного обеспечения. В SPICE используется схема с различными уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам.

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

83 83 Стандарт SPICE Безусловно, совершенствование процессов жизненного цикла программного обеспечения абсолютно необходимо. Однако следует иметь в виду, что построение «более зрелого» процесса разработки не обязательно обеспечивает создание более качественного программного обеспечения. Это хотя и связанные, но совершенно различные процессы. Использование формальных моделей и методов позволяет создавать понятные, непротиворечивые спецификации на разрабатываемое программное обеспечение. Конечно, внедрение таких методов имеет смысл, хотя оно весьма дорого и трудоемко, а возможности их применения весьмаu1086 ограничены. Основная же проблема - проблема сложности разрабатываемого программного обеспечения с совершенствованием процессов разработки пока не разрешена. Создание программного обеспечения по-прежнему предъявляет повышенные требования к квалификации тех, кто этим занимается: проектировщикам программного обеспечения и непосредственно программистам.

84 84 Резюме 1 Технологии программирования: Стихийный подход Структурный подход Модульный подход Объектно-ориентированный подход Компонентный подход CASE-технологии JAVA подход

85 85 Резюме 2 Для описания жизненного цикла создания ПО используются модели: Каскадная модель Каскадная модель с промежуточным контролем Спиральная модель CASE-технологии RAD-технологии

86 86 Резюме 3 Для оценки качества ПО разработаны стандарты: ISO 9000 CMM SPICE

87 87