Разработка программного продукта

1. Условия успешности бизнеса

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

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

Технология программирования (ТП) - технология
разработки программного средства (ПС),
включающая все процессы, начиная с момента
зарождения идеи этого средства. Результатом
применения ТП является программа, действующая в
заданной вычислительной среде, хорошо отлаженная
и документированная, доступная для понимания и
развития в процессе сопровождения.
Процесс разработки ПС и методы оценивания
продуктов стандартизованы (ISO/IEC 12207, 9126 и
др.). Все это способствует повышению эффективности
проектирования, разработки, тестирования и оценки
качества ПС.

3. Программная инженерия

Программная инженерия является отраслью
информатики, которая изучает вопросы построения
компьютерных программ, отражает закономерности
развития программирования, обобщает опыт
программирования в виде комплекса знаний и
правил регламентации инженерной деятельности
разработчиков ПС.
Международным комитетом при американском
объединении компьютерных специалистов ACM
(Association for Computing Machinery) и институте
инженеров по электронике и электротехнике IEEE
было создано ядро знаний SWEBOK (Software
Engineering Body of Knowledge) (2001, 2003 гг.).

4. Программная инженерия

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

5. Программная инженерия

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

6. Процессы жизненного цикла программных средств

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

7. Процессы жизненного цикла программных средств

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

8. Процессы жизненного цикла программных средств

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

9. Процессы жизненного цикла программных средств

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

10. Процессы жизненного цикла программных средств

Формальные преобразования. Этот подход включает
разработку формальных спецификаций ПС и
превращение их в программы путем корректных
преобразований. На этом подходе базируется
компьютерная технология (CASE-технология)
разработки ПС.
Сборочное программирование. Этот подход
предполагает, что ПС конструируется из компонент,
которые уже существуют. Должна быть библиотека
таких компонент, каждая из которых может многократно
использоваться в разных ПС. Процесс разработки ПС при
данном подходе состоит скорее из сборки программ из
компонент, чем из их программирования.

11. Водопадный подход разработки ПС. Каскадная модель ЖЦ ПС

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

12. Водопадный подход разработки ПС. Каскадная модель ЖЦ ПС

13. Исследовательское программирование. Инкрементная модель ЖЦ ПС

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

14. Исследовательское программирование. Инкрементная модель ЖЦ ПС

15. Исследовательское программирование. Инкрементная модель ЖЦ ПС

16. Прототипирование

Прототипирование – это процесс создания модели
требуемого программного средства. Прототипирование
основывается на многократном повторении итераций, в
которых участвуют заказчик и разработчик.
Спиральная модель ЖЦ разработки ПС

17. Прототипирование

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

18. Основное назначение моделей ЖЦ ПС

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

19. Основное назначение моделей ЖЦ ПС

На сегодня основой формирования новой модели ЖЦ для
конкретной прикладной системы является международный
стандарт ISO/IEC 12207 «Информационная технология.
Процессы жизненного цикла программных средств»,
который задает полный набор процессов, охватывающий
все возможные виды работ и задач, связанных с
построением ПС, начиная с анализа предметной области и
кончая изготовлением соответствующего продукта. Данный
стандарт содержит основные и вспомогательные процессы.

20. Схема основных процессов ЖЦ ПС

21. Схема вспомогательных процессов ЖЦ ПС

22.

Являясь стандартом высокого уровня, стандарт ISO/IEC 12207 не
задает детали того, как надо выполнять задачи, составляющие
процессы.
Процессы и задачи приведены в стандарте в наиболее общей
последовательности. В зависимости от проекта процессы и задачи
стандарта выбираются, упорядочиваются и включаются в модель
ЖЦ.
При применении они могут перекрывать, прерывать друг друга,
выполняться итерационно или рекурсивно. Это позволяет
реализовать с его помощью произвольную модель ЖЦ ПС.
Из данного стандарта можно выбрать только те процессы, которые
более всего подходят для реализации конкретной ПС.
Обязательными являются основные процессы, которые
присутствуют во всех известных моделях ЖЦ.
Кроме этого, стандарт ISO/IEC 12207 предоставляет основу для
принятия ряда других связанных с ним стандартов, таких как
стандарты по управлению ПС, обеспечению качества, верификации
и валидации, управления конфигурацией, метриками ПС и т.д.

23. Структура стандарта ГОСТ ISO/IEC 12207

Первый раздел описывает область применения данного
стандарта.
Назначение. Устанавливает общую структуру процессов
ЖЦ ПС, на которую можно ориентироваться в
программной индустрии. Определяет процессы, работы
и задачи, которые используются: при приобретении
системы, содержащей программные средства, или
отдельно поставляемого программного продукта; при
оказании программной услуги, а также при поставке,
разработке, эксплуатации и сопровождении
программных продуктов.

24. Структура стандарта ГОСТ ISO/IEC 12207

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

25. Структура стандарта ГОСТ ISO/IEC 12207

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

26. Структура стандарта ГОСТ ISO/IEC 12207

Второй раздел описывает стандарты, на которые есть
ссылки.
ГОСТ Р ИСО 9001-96 Системы качества. Модель
обеспечения качества при проектировании, разработке,
производстве, монтаже и обслуживании
ГОСТ Р ИСО/МЭК 9126-93 Информационная технология.
Оценка программной продукции. Характеристики качества
и руководства по их применению
ИСО/МЭК 2382-1-93 Информационная технология.
Словарь. Часть 1. Основополагающие термины
ИСО/МЭК 2382-20-90 Информационная технология.
Словарь. Часть 20. Разработка систем
ИСО 8402-94 Управление качеством и обеспечение
качества. Словарь

27. Структура стандарта ГОСТ ISO/IEC 12207

Третий раздел расшифровывает основные определения,
которые используются в тексте стандарта.
Четвертый раздел описывает прикладную область
применения данного стандарта. Этот раздел описывает
структуру стандарта для удобства его использования.
Пятый раздел описывает основные процессы
жизненного цикла ПС:
заказа;
поставки;
разработки;
эксплуатации;
сопровождения.

28. Структура стандарта ГОСТ ISO/IEC 12207

Шестой раздел описывает вспомогательные процессы:
документирования;
управления конфигурацией;
обеспечения качества;
верификации;
аттестации (валидация);
совместного анализа;
аудита;
решения проблем.
Седьмой раздел описывает организационные процессы:
управления;
создания инфраструктуры;
усовершенствования;
обучения.

29. Внешнее описание программного средства

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

30. Определение требований к программному средству

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

31. Виды и свойства требований

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

32. Виды и свойства требований

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

33. Виды и свойства требований

Требования должны обладать следующими важными
свойствами.
Ясность, недвусмысленность - однозначность понимания
требований заказчиком и разработчиками.
Полнота и непротиворечивость.
Необходимый уровень детализации. Это могут быть
описание свойств предметной области или техническое
задание.
Прослеживаемость. Важно видеть то или иное требование в
различных моделях, документах, в коде системы.
Тестируемость и проверяемость.
Модифицируемость. Определяет процедуры внесения
изменений в требования.

34. Цикл работы с требованиями

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

35. Цикл работы с требованиями

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

36. Варианты формализации требований

Разработанные требования представляются в специальном
документе, который является основой заключения
контракта на разработку системы между заказчиком и
разработчиком.
Формализация требований в проекте может быть разной –
это зависит от его величины, принятого процесса
разработки, используемых инструментальных средств, а
также тех задач, которые решают формализованные
требования. Более того, может существовать параллельно
несколько формализаций, решающих различные задачи.
Неформальная постановка требований в переписке по
электронной почте. Хорошо работает в небольших
проектах, при вовлеченности заказчика в разработку.

37. Варианты формализации требований

Требования в виде документа – описание предметной
области и ее свойств, техническое задание как приложение к
контракту, функциональная спецификация для
разработчиков.
Требования в виде графа в одном из средств поддержки
требований
(IBM Rational RequisitePro, DOORS, Borland CaliberRM и
др.). Такое представление требований удобно при их частом
изменении, при отслеживании выполнения, при «привязке»
к задачам, людям, тестам, кодам.
Формальная модель требований для верификации,
модельно-ориентированного тестирования и т.д.

38. Способы разработки определения требований

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

39. Способы разработки определения требований

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

40. Структура внешнего описания

Во внешнем описании выделяются две самостоятельные его
части. Описание поведения ПС определяет функции, которые
должно выполнять ПС, и потому его называют
функциональной спецификацией ПС. Функциональная
спецификация определяет допустимые фрагменты программ,
реализующих декларированные функции. Требования к
качеству ПС должны быть сформулированы так, чтобы
разработчику были ясны цели, которые он должен стремиться
достигнуть при разработке этого ПС. Эту часть внешнего
описания называют спецификацией качества ПС
Обычно разработка спецификации качества предшествует
разработке функциональной спецификации ПС, так как
некоторые требования к качеству ПС могут предопределять
включение в функциональную спецификацию специальных
функций (например, защиты от несанкционированного
доступа).

41. Спецификация качества программного средства

Под качеством ПС принято понимать совокупность характеристик,
относящуюся к его способности удовлетворять установленным
потребностям.
Общепринятой моделью, лежащей в основе оценки качества ПС,
является модель, регламентированная в стандарте ISO/IEC 91261:2001 «Информационная технология. Оценка программного
продукта. Характеристики качества и руководства по их
применению». В соответствии с данным стандартом модель
качества ПС представляет собой иерархическую структуру,
состоящую из трех уровней.
1. Характеристики качества (цели) - то, что мы хотим видеть в ПС.
2. Атрибуты качества - свойства ПС, показывающие приближение
к цели.
3. Метрики - количественные характеристики степени наличия
атрибутов.
Верхний уровень данной модели представлен шестью основными
характеристиками качества ПС. Это функциональность,
надежность, практичность, эффективность, сопровождаемость и
мобильность.

42. Спецификация качества программного средства

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

43. Спецификация качества программного средства

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

44. Спецификация качества программного средства

Разработка спецификации качества сводится к
построению модели качества ПС. В этой модели должен
быть перечень всех свойств, которыми требуется
обеспечить ПС, и которые в совокупности образуют
приемлемое качество ПС.
Каждое из этих свойств должно быть конкретизировано:
оценка его наличия в ПС;
степень обладания им этим ПС.
Для конкретизации качества ПС для каждой из
характеристик используются примитивы качества ПС,
регламентированные в стандарте ISO/IEC 9126.

45. Определения используемых примитивов качества ПС

Примитивы качества
Завершенность
Временная
эффективность
Эффективность по
ресурсам
Свойство
Степень обладания необходимыми частями для
выполнения своих функций
Приемлемость величины погрешности в
выдаваемых программами ПС результатах
Способность выполнять предписанные функции без
помощи других компонент ПС
Способность ПС работать на разнообразном
аппаратном обеспечении (различных типах
компьютеров)
Способность корректного функционирования при
задании неправильных входных данных
Способность противостоять преднамеренным или
нечаянным деструктивным действиям пользователя
Наличие, полнота, понятность, доступность
документации, необходимой для применения ПС
Наличие информации, необходимой для понимания
назначения ПС, существующих ограничений,
входных данных и результатов работы компонент, а
также текущего состояния программ
Облегчение задания входных данных, а также
обеспечение выдачи сведений в понятной форме
Способность выполнять возложенные функции за
определенный отрезок времени
Способность выполнять функции при определенных
ограничениях на используемые ресурсы (память)
Эффективность по
устройствам
Экономичность использования устройств машины
для решения поставленной задачи
Точность
Автономность
Независимость от
устройств
Устойчивость
Защищенность
П-документи
рованность
Информативность
Коммуникабельность

46. Определения используемых примитивов качества ПС

С-документи
рованность
Понятность
Структурированность
Удобочитаемость
Расширяемость
Легкость изменения
Модульность
Наличие документации, отражающей требования к
ПС, и результаты различных этапов разработки ПС
Степень доступности назначения, допущений и
ограничений, входных данных и результатов работы
программ ПС, тексты этих программ
Свойство, характеризующее программы ПС с точки
зрения организации взаимосвязанных их частей в
единое целое
Легкость восприятия текста программ ПС (отступы,
фрагментация, форматирование)
Способность ПС к использованию большего объема
памяти или расширению функциональных
возможностей отдельных компонент
Простота внесения изменений и доработок на всех
этапах и стадиях жизненного цикла ПС
Организация программ ПС из таких дискретных
компонент, что изменение одной из них оказывает
минимальное воздействие на другие компоненты

47. Зависимость характеристик качества от примитивов качества ПС

Характеристики
качества
Функциональность
Надежность
Легкость применения
Эффективность
Мобильность
Сопровождаемость
(изучаемость)
Сопровождаемость
(модифицируемость)
Примитивы качества
Завершенность
Завершенность, точность, автономность,
устойчивость, защищенность
П - документированность, информативность
(применительно к документации по применению),
коммуникабельность, устойчивость, защищенность.
Временная эффективность, эффективность по
памяти, эффективность по устройствам
Независимость от устройств, автономность,
структурированность, модульность
Минимизация усилий по изучению программ и
документации ПС: С-документированность,
информативность (применительно к Сдокументации), понятность, структурированность,
удобочитаемость
Упрощение внесений в ПС необходимых изменений
и доработок: расширяемость, легкость изменения,
структурированность, модульность.

48. Функциональная спецификация программного средства

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

49. Функциональная спецификация программного средства

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

50. Функциональная спецификация программного средства

В третьей части перечисляются все существенные
случаи, когда ПС не может нормально выполнить ту или
иную свою функцию:
– ошибки взаимодействия с пользователем;
– попытки применить функцию к данным, не
удовлетворяющим ограничениям, указанным в ее
спецификации;
– получение результата, нарушающего заданное
ограничение.
Для каждого такого случая должна быть определена
реакция ПС.
На основании описаний принимается решение на заключение
договора на разработку ПС. Таким документом является
техническое задание, требования к которому определяются
ГОСТом 19.201 «Техническое задание. Требования к
содержанию и оформлению»

51. Методы контроля внешнего описания ПС

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

52. Методы контроля внешнего описания ПС

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

53. Методы контроля внешнего описания ПС

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

54. Проектирование программных средств

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

55. Проектирование программных средств

Проектирование ПС – это процесс, следующий за этапами
анализа и формирования требований. Модели анализа
поставляют этапу проектирования исходные сведения для
работы. Информационная модель описывает информацию,
которую должно обрабатывать ПС. Функциональная модель
определяет перечень функций обработки. Поведенческая
модель закрепляет динамику системы. На выходе этапа
проектирования – разработка данных, разработка
архитектуры и процедурная разработка ПС

56. Проектирование программных средств

57. Особенности этапа проектирования

Проектирование - итерационный процесс, при помощи
которого требования к ПС транслируются в инженерные
представления ПС. Вначале эти представления дают
концептуальную информацию, последующие уточнения
приводят к формам близким к текстам на языках
программирования.
Обычно в проектировании выделяют две ступени:
предварительное проектирование и детальное
проектирование.
Предварительное проектирование формирует абстракции
архитектурного уровня.
Детальное проектирование уточняет эти абстракции,
добавляет подробности алгоритмического уровня.
Еще выделяют интерфейсное проектирование, цель которого
- сформировать графический интерфейс пользователя (GUI).

58. Информационные связи процесса проектирования

59. Этапы развития программирования

Технологии
программирования
Первый этап. Язык Ассемблера. Компиляторы
Второй этап. Языки высокого уровня. Процедурное
программирование
Третий этап. Ошибки в программах
Четвертый этап. Структурное программирование.
Интегрированные среды разработки программ
Современное состояние. Объектно ориентированный подход. RAD-технология
Перспективы. Компонентный подход и объектное
моделирование распределенных систем

60. Основные проблемы в области создания программного обеспечения.

Необходимо:
Ускорить и облегчить процесс
разработки;
Повысить надежность программ,
максимально избавив их от ошибок;
Облегчить сопровождение и
модификацию программных продуктов.

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

- это совокупность методов и
средств разработки (написания)
программ и порядок применения
этих методов и средств.

62. переслать содержимое ячейки памяти в один из регистров процессора, а затем из регистра – в другую ячейку памяти

На ранних этапах развития программирования
программы писались в виде
последовательности машинных команд.
Простое присваивание У X , может выглядеть
как последовательность шестнадцатеричных
кодов, например, таким образом:
B82201
8B0126
переслать содержимое
ячейки
памяти в один из
регистров процессора, а
затем из регистра – в другую
ячейку памяти

63. Первый этап

Язык
Ассемблера
Первым шагом в развитии языков программирования
стало появление языка Ассемблера (assembler –
сборщик). Присваивание У X можно записать:
Mov AX, X - занести значение переменной X в
регистр AX
Mov Y, AX - занести значение регистра AX в
переменную Y

64. Первый этап

Компиляторы
В области средств разработки программ
первый этап ознаменовался появлением первых
компиляторов – программ перевода
программ с языка Ассемблера в
машинные коды.
Задачу
непосредственной
привязки
программы к условиям данной ЭВМ решала
другая программа – компоновщик (linker).

65. Второй этап. Языки высокого уровня.

Ассемблер оставался машинно-зависимым
языком, поскольку для программирования на
нем необходимо было, как минимум, знать
систему команд процессора и организацию
памяти конкретного типа компьютера.
Имела место проблема переносимости
программных продуктов с одной платформы
ЭВМ на другую.
Любая, достаточно большая программа на языке
Ассемблера, могла содержать тысячи строк
кода. Естественно, что это приводило к
появлению большого количества ошибок.

66. Второй этап. Языки высокого уровня.

Отличительными особенностями языков
высокого уровня являются:
1. Полная независимость от аппаратной
платформы
полная,конструкция,
если говорить о
Оператор(почти
- языковая
конкретных
реализациях);
по виду максимально
приближенная к
2.
Использование обозначениям
вместо мнемокодов
математическим
команд
операторов.
и формализованному
естественному
языку
С конца 50-х годов - Фортран, Алгол,
затем Паскаль, PL/1, Ada, C

67. Второй этап. Языки высокого уровня.

На рассматриваемом этапе не появилось
принципиально новых средств создания
программ. Развитие компиляторов шло по
пути
повышения
эффективности
создаваемого кода и ускорения работы.
В этом отношении особенно знамениты
компиляторы фирмы Borland для таких
языков, как C и Паскаль.

68. Второй этап. Процедурный стиль программирования.

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

69. Третий этап. Ошибки в программах.

Вначале были разработаны методики
тестирования программ – проверки их
алгоритмической (семантической,
смысловой) правильности - внешнее
тестирование, модульное, нисходящее и
восходящее тестирование.
Далее стали развиваться методы
верификации – формальной проверки
правильности программ.

70. Третий этап. Верификация программ.

Утверждалось, что если имеем:
формальное описание синтаксиса языка,
формальное описание семантики,
формальное
описание
правильного
результата программы,
то из анализа текста можно строго
математически вывести заключение о
правильности программы.

71. Третий этап. Верификация программ.

Формы Бэкуса – Наура позволяют описать
синтаксис любого языка в терминах некоторого
метаязыка.
<алфавит>::=<буквы>|<цифры>|<ограничители>
<цифры>::= 1|2|3|4|5|6|7|8|9|0
Для описания смыслового содержания подобных
конструкций были разработаны специальные
грамматики, с помощью которых удалось, хотя и
с большим трудом, описать, например, такие языки
как PL/1 и Паскаль.

72. Третий этап. Верификация программ.

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

73. Четвертый этап. Структурное программирование.

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

74. Четвертый этап. Принцип декомпозиции

Упор на создание методов программирования
привел к появлению структурного подхода к
программированию. Это первый законченный
метод программирования, поскольку он охватывает
все этапы создания программного продукта – от
первоначального
замысла
до
кодирования
программы. Он основан на процедурном стиле
программирования,
дополненном
рядом
принципов, главным из которых является принцип
разбиения (декомпозиции) решаемой задачи на
отдельные подзадачи.

75. Четвертый этап. Интегрированные среды разработки программ.

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

76. Современное состояние. Объектно - ориентированный подход.

Изменился характер решаемых с помощью компьютера
задач. В настоящее время это, главным образом,
задачи обработки распределенной информации
различного вида (многосредовые, мультимедиа
данные).
Образовался так называемый семантический разрыв
между структурой современных задач, решаемых ПО,
и процедурным подходом. Это привело к появлению
объектно-ориентированного
подхода
к
программированию, который в настоящее время
считается стандартом.
Объектный
подход
привел
к
появлению
языков
программирования нового поколения, среди которых отметим
С++, Object (Delphi) Pascal, Java, Visual Basic.

77. Современное состояние. RAD-технология.

Бурное развитие ПО привело к появлению мощных
многозадачных
операционных
систем
с
графическим
интерфейсом
пользователя
(Windows). Программирование для таких систем
RAD Это, в свою очередь
стало нелегкой задачей.
стимулировало
появление
визуальных сред
Rapid Application
Development
программирования,
основанных
– быстрая разработка
программ на RAD
технологии. Рассмотрим особенности подобных
систем
на
примере
визуальной
среды
программирования Delphi.

78. Компонентный подход и объектное моделирование распределенных систем

(Unified
Modeling
Language
–
унифицированный язык моделирования).
Все
шире
применяются
новые
средства
проектирования программ, основанные на этом
языке, например пакет объектного моделирования
Rational Rose.
UML

79. Компонентный подход и объектное моделирование распределенных систем

В сфере методик создания программных продуктов
большую
популярность
получает
CBPD
(Component
Based
Program
Design
–
проектирование программ, основанное на
компонентах).
Главная идея этого подхода проста: составлять
программы из поставляемых на рынке готовых
компонентов, как из деталей конструктора или
кубиков.

80. Компонентный подход и объектное моделирование распределенных систем

С компонентным подходом тесно связана технология
создания распределенных программных систем. Части
программ предполагается размещать в разных приложениях,
которые, возможно, размещены на различных компьютерах,
соединенных локальной, либо глобальной сетью. В этом
направлении развиваются две технологии:
DCOM (Distributed Component Object Model –
модель распределенных компонентов)
CORBA(Common
Object
Request
Broker
Architecture – общая архитектура объектного
брокера запросов).

81. IBM Rational Unified Process (RUP - новый подход к разработке ПС)

IBM Rational Unified Process (RUP новый подход к разработке ПС)
четко определенный процесс
(технологическая процедура), описывающий
структуру жизненного цикла проекта, роли и
ответственности отдельных исполнителей,
выполняемые ими задачи и используемые в
процессе разработки модели, отчеты и т.д.;
готовый продукт, предоставляемый в виде
веб-сайта, содержащего все необходимые модели и
документы с описанием процесса.

82. IBM Rational Unified Process (RUP - новый подход к разработке ПС)

IBM Rational Unified Process (RUP новый подход к разработке ПС)
Основными принципами RUP являются:
итерационная разработка
управление
процессом
на
основе
прецедентов использования
ориентация на архитектуру.

83. IBM Rational Unified Process. Итерационный процесс разработки ПС

Создавать современные сложные программные
системы последовательно, т.е. сначала определять
все проблемы, затем принимать все проектные
решения, формировать ПС и, наконец, проверять
изделие, невозможно. Такой каскадный подход
(«водопад») в современной информационной
индустрии не оправдывает себя, поскольку его
использование часто приводит к непредсказуемому
увеличению проектной стоимости и сроков
выпуска
ПС.
Эффективной
альтернативой
«водопаду»
служит
итерационный
процесс
разработки ПС.

84. IBM Rational Unified Process

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