Введение в технологию программирования. Лекция 1

1.

Введение в технологию
программирования
Лекция 1

2.

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

3.

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

4.

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

5.

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

6.

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

7.

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

8.

Модель с промежуточным
контролем

9.

Инкрементная модель
Поставка 1-го
инкремента
1-й инкремент
Анализ
Проекти
рование
Кодирование
Поставка 2-го
инкремента
2-й инкремент
Анализ
Проекти
рование
Кодирование
Тестирование
Поставка 3-го
инкремента
3-й инкремент
Анализ
Тестирование
Проекти
рование
Кодирование
Тестирование

10.

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

11.

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

12.

Стадии жизненного цикла в картинках

13.

Внешнее описание =
Определение требований +
Спецификация качества +
Функциональная спецификация

14.

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

15.

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

16.

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

17.

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

18.

Международной организацией по стандартизации (ISO)
разработан перечень простых измеряемых и однозначно
понимаемых разработчиками примитивов качества
Завершённость (completeness) – свойство, характеризующее
степень обладания ПС всеми необходимыми частями и чертами,
требующимися для выполнения своих явных и неявных
функций.
Точность (accuracy) – мера, характеризующая приемлемость
величины погрешности в выдаваемых ПС результатах.
Автономность (self-containedness) – способность ПС выполнять
предписанные функции без помощи или поддержки других
компонентов программного обеспечения.
Устойчивость (robustness) – способность ПС продолжать
корректное функционирование, несмотря на ошибки во входных
данных.
Защищённость (defensiveness) – способность ПС
противостоять преднамеренным или случайным деструктивным
действиям пользователя.

19.

Международной организацией по стандартизации (ISO)
разработан перечень простых измеряемых и однозначно
понимаемых разработчиками примитивов качества
П-документированность (u-documentation) – свойство,
характеризующее наличие, полноту, понятность и наглядность
учебной, инструктивной и справочной документации,
необходимой для применения ПС.
Информативность (accountability) – свойство, характеризующее
наличие в составе ПС информации, необходимой и достаточной
для понимания назначения, принятых предположений,
ограничений, входных данных и результатов работы, а также
текущего состояния программ в процессе их функционирования.
Коммуникабельность (communicativeness) – характеристика
степени, в которой ПС облегчает задание входных данных, а
также способность выдавать полезные сведения в простой
форме и с понятным содержанием.
Эффективность по времени (time efficiency) – способность
выполнять возложенные на ПС функции за требуемый
временной промежуток.

20.

Международной организацией по стандартизации (ISO)
разработан перечень простых измеряемых и однозначно
понимаемых разработчиками примитивов качества
Эффективность по ресурсам (resource efficiency) –
способность выполнять возложенные на ПС функции при
определённых ограничениях на объём памяти.
Эффективность по устройствам (device efficiency) – мера,
характеризующая экономичность использования устройств
компьютера для выполнения поставленной задачи.
С-документированность (documentation) – свойство,
характеризующее наличие и полноту документации,
отражающей внутреннюю структуру ПС, обоснование принятых
в процессе разработки решений и т.п.
Понятность (understandability) – согласованность,
самодокументированность (наличие и ясность комментариев,
значащие имена объектов), четкость и понятность текстов
программ.
Структурированность (structuredness) – взаимосвязанность
частей ПС в единое целое по определённым принципам
(например, по принципам структурного программирования).

21.

Международной организацией по стандартизации (ISO)
разработан перечень простых измеряемых и однозначно
понимаемых разработчиками примитивов качества
Удобочитаемость (readability) – свойство, характеризующее
лёгкость восприятия текстов программ (отступы,
фрагментация, форматированность).
Расширяемость (augmentability) – способность к наращиванию
объёма данных или расширению функциональных
возможностей.
Лёгкость изменения (modifiability) – простота внесения
необходимых изменений и дополнений на всех стадиях
жизненного цикла ПС.
Модульность (modularity) – разбиение ПС на модули таким
образом, чтобы изменение одного из них оказывало
минимальное воздействие на другие модули.
Независимость от устройств (device independence) –
способность ПС работать на разнообразном аппаратном
обеспечении.

22.

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

23.

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

24.

Лекция окончена
Спасибо за внимание
☺