'

Технология программирования

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

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


Слайд 23

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


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

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


Слайд 28

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


Слайд 29

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


Слайд 30

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


Слайд 31

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


Слайд 32

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


Слайд 33

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


Слайд 34

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


Слайд 35

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


Слайд 36

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


Слайд 37

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


Слайд 38

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


Слайд 39

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


Слайд 40

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


Слайд 41

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


Слайд 42

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


Слайд 43

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


Слайд 44

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


Слайд 45

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


Слайд 46

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


Слайд 47

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


Слайд 48

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


Слайд 49

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


Слайд 50

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


Слайд 51

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


Слайд 52

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


Слайд 53

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


Слайд 54

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


Слайд 55

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


Слайд 56

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


Слайд 57

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


Слайд 58

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


Слайд 59

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


Слайд 60

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


Слайд 61

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


Слайд 62

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


Слайд 63

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


Слайд 64

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


Слайд 65

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


Слайд 66

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


Слайд 67

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


Слайд 68

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


Слайд 69

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


Слайд 70

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


Слайд 71

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


Слайд 72

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


Слайд 73

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


Слайд 74

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


Слайд 75

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


Слайд 76

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


Слайд 77

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


Слайд 78

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


Слайд 79

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


Слайд 80

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


Слайд 81

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


Слайд 82

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


Слайд 83

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


Слайд 84

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


Слайд 85

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


Слайд 86

87


×

HTML:





Ссылка: