'

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

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





Слайд 0

Технологии программирования Software engineering Евгений Александрович Мирошниченко доцент кафедры вычислительной техники, к. т. н. В США водопроводчик учится около 8 лет. И это чтобы починить мой чёртов унитаз. Ну, и сколько же вы должны учиться, чтобы вам позволили создавать программы для самолетов с сотнями людей на борту? Джеймс Коплиен


Слайд 1

Литература, вопросы к экзамену http://metod.ce.cctpu.edu.ru/edu/df/se/ Брауде Э. Технология разработки программного обеспечения. — СПб.: «Питер», 2004. — 655 с.: ил. Брукс Ф. Мифический человеко-месяц или как создаются программные си-стемы: Пер. с англ. — СПб.: Символ-Плюс, 1999. — 304 с.: ил. Орлов С.А. Технологии разработки программного обеспечения, 2-е изд. — СПб.: "Питер", 2003. — 473 с.: ил. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. — СПб.: Питер, 2002. — 496 с.: ил. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб.: Питер, 2001. — 368 с.: ил. Дастин Э., Рэшка Дж., Пол Дж. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация: Пер. с англ. — М: Лори, 2003. — 567 с.: ил. Йордан Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. — М.: Лори, 2003. — 255 с.


Слайд 2

Виды обеспечения ВС математическое: методы, алгоритмы; лингвистическое: языки, способы взаимодействия; информационное: данные; программное: программы; техническое: аппаратные средства; методическое: документы, методики; организационное: правила, регламенты, процедуры. Прошедшая испытания программа или программная система, полностью готовая для продажи (поставки) и снабженная всей необходимой документацией, называется программным продуктом, изделием или средством (software product, production program).


Слайд 3

Software engineering Применение систематического, упорядоченного, измеримого подхода к разработке, использованию и сопровождению ПО, то есть использование инженерного искусства в ПО. Создание подходов п. (1)


Слайд 4

Кризис ПО


Слайд 5

в 1995 г. ожидалось, что только 9 % проектов, выполняемых крупными компаниями, будут завершены в срок и без превышения запланированного бюджета; 52 % проектов должны были стоить в среднем 189 % от их первоначально оцененной стоимости; в то же время 31 % всех проектов вообще ожидало приостановление или полное прекращение, причем затраты на них — ничем не компенсируемые убытки — оценивались ни много ни мало в 81 млрд долл. Через десятилетие, в 2004 г. 18 % проектов провалились, 53 % (более половины!) — не уложились в заданный бюджет или сроки, только 29 % были признаны успешными.


Слайд 6

Сложность разработки ПО Управление сложностью — суть программирования. Брайан Керниган Сложность предметной области Внутренняя сложность программ Отсутствие хороших способов представления больших систем Трудности управления процессом разработки Изменение требований к программе в процессе её разработки


Слайд 7

Жизненный цикл программного продукта ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes» ГОСТ Р ИСО/МЭК 12207—2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств


Слайд 8

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


Слайд 9

Группы процессов ЖЦ a) процессы соглашения — 2 b) процессы организационного обеспечения проекта — 5 c) процессы проекта — 7; d) технические процессы — 11 e) процессы реализации программных средств — 7 f) процессы поддержки программных средств — 8 g) процессы повторного применения программных средств — 3


Слайд 10

Процессы соглашения Поставка Приобретение


Слайд 11

Процессы организационного обеспечения проекта a) процесс менеджмента модели жизненного цикла; b) процесс менеджмента инфраструктуры; c) процесс менеджмента портфеля проектов; d) процесс менеджмента людских ресурсов; e) процесс менеджмента качества.


Слайд 12

Процессы проекта Процессы менеджмента проекта процесс планирования проекта; процесс управления и оценки проекта. Процессы поддержки проекта процесс менеджмента решений; процесс менеджмента рисков; процесс менеджмента конфигурации; процесс менеджмента информации; процесс измерений.


Слайд 13

Технические процессы a) определение требований правообладателей b) анализ системных требований c) проектирование архитектуры системы d) процесс реализации e) процесс комплексирования системы f) процесс квалификационного тестирования системы g) процесс инсталляции программных средств h) процесс поддержки приемки программных средств i) процесс функционирования программных средств j) процесс сопровождения программных средств k) процесс изъятия из обращения программных средств


Слайд 14

Процессы реализации программных средств а) процесс анализа требований к программным средствам; b) процесс проектирования архитектуры программных средств; c) процесс детального проектирования программных средств; d) процесс конструирования программных средств; e) процесс комплексирования программных средств; f) процесс квалификационного тестирования программных средств


Слайд 15

Процессы поддержки программных средств a) процесс менеджмента документации программных средств; b) процесс менеджмента конфигурации программных средств; c) процесс обеспечения гарантии качества программных средств; d) процесс верификации программных средств; e) процесс валидации программных средств; f) процесс ревизии программных средств; g) процесс аудита программных средств; h) процесс решения проблем в программных средствах.


Слайд 16

Процессы повторного применения программных средств a) процесс проектирования доменов; b) процесс менеджмента повторного применения активов; c) процесс менеджмента повторного применения программ.


Слайд 17

Модели разработки Водопадная (каскадная, последовательная) Эволюционная (итеративная, инкрементальная)


Слайд 18

Водопадная (waterfall)


Слайд 19

Эволюционная (IID)


Слайд 20

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


Слайд 21

Методологии разработки Единая система программной документации (ЕСПД) Microsoft Solutions Framework (MSF) Rational Unified Process (RUP) Agile-методологии Экстремальное программирование (eXtreme Programming, XP) Adaptive Software Development (ASD), Lean Development, SCRUM, Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal Clear


Слайд 22

Выбор и адаптация методологии Масштаб проекта Надёжность программы Распределённость команды Новизна проекта Требования заказчика Долговечность проекта


Слайд 23

Управление проектом Управлять программистами — это всё равно, что пытаться пасти котов. Грег Сетл Проект = Design = модель будущей системы Проект = Project = комплекс действий, направленных на создание продукта или услуги


Слайд 24

Основные задачи Планирование (planning) Контроль исполнения (tracking and oversight)


Слайд 25

Планирование Структура декомпозиции работ (work breakdown structure, WBS), или иерархическая структура работ Исполнители Время Планирование = отображение списка работ на список исполнителей во времени.


Слайд 26

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


Слайд 27

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


Слайд 28

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


Слайд 29

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


Слайд 30

Внедрение и управление Внедрение управления конфигурацией: выбор и внедрение системы управления версиями (version control system); разработка организационного обеспечения (регламента). Дальнейшее управление: управление составом конфигурации; управление правами доступа к системе управления версиями; разрешение проблем; резервное копирование (backup).


Слайд 31

Оценка качества процесса разработки Насколько «правильно» данная организация производит продукцию? ISO серии 9000 CMM (Capability Maturity Model) — модель зрелости возможностей ISO/IEC 15504: Information Technology — Software Process Assessment = SPICE (Software Process Improvement and Capability dEtermination)


Слайд 32

CMM (Capability Maturity Model)


Слайд 33

CMM 1. Начальный уровень (Initial level) В организации царит анархия при разработке, нет четких процессов управления и четких инженерных процессов. Могут существовать стандарты и инструкции, но им никто не следует. Неравномерность процесса разработки — наличие затиший и авралов в работе 2. Повторяемый уровень (Repeatable level) Внедрено управление проектами, управление конфигурацией. Полная зависимость от конкретных личностей сохраняется, а организация имеет сильную тенденцию «сползания» к начальному уровню. 3. Определённый уровень (Defined level) Процессы управления интегрированы с инженерными процессами (методологий разработки) в единый стандартный документированный программный процесс. Нет деградации процесса в стрессовых ситуациях 4. Управляемый уровень (Managed level) Устанавливаются количественные показатели качества, которые собираются с помощью специального измерительного инструментария и оперативно анализируются менеджерами. Достигается полное управление проектами и предсказуемость программного процесса и качества программ. 5. Оптимизирующий уровень (Optimizing level) Организация постоянно и целенаправленно занимается улучшением существующих процессов, и делает это полностью контролируемым образом. Организация нацелена на предупреждение дефектов (defect prevention).


Слайд 34

CMMI В 2000 г. SEI предложил сменить CMM новой, улучшенной моделью — CMMI (Capability Maturity Model for Integration). CMMI фактически является обобщением CMM, поскольку рассматривает не только процессы разработки, как CMM, но и другие процессы ЖЦ (приобретение, сопровождение и т. д.) Часто используется сокращение CMM/CMMI.


Слайд 35

Анализ требований Анализ требований представляет собой исследование предметной области, выявление роли и места будущей программной системы, её основных функций и характеристик. Формальным результатом анализа является спецификация требований (requirements/product/preliminary specification) в том или ином виде.


Слайд 36

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


Слайд 37

Техническое задание ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению ГОСТ 34.602-89 Информационная технология. Техническое задание на создание автоматизированной системы


Слайд 38

Варианты использования Автор: Айвар Якобсон (Ivar Jacobson) Вариант использования — это формальное описание взаимодействия системы и пользователя при решении конкретной задачи. Каждый ВИ нацелен на конкретную бизнес-цель (конкретную задачу). «Usage scenario» ? «usage case»? «use case»


Слайд 39

Варианты использования Краткий (brief) ВИ Бессистемный (casual) ВИ Детальный (detailed) ВИ 1. Название (Name). Краткое, максимально понятное, в виде команды (что сделать). 2. Цель (Goal). Краткая (до нескольких предложений) характеристика задачи, которую должен в результате решить ВИ. 3. Начальное состояние (Initial state). Формулировка условий, при которых данный ВИ может быть инициирован. 4. Основной сценарий (Main scenario). Сценарий — это последовательность шагов, описывающая процесс решения задачи, которой посвящен ВИ. 5 и т. д. — альтернативные сценарии


Слайд 40

Варианты использования Название: Отправить электронное письмо. Цель: Отправить созданное письмо с проверкой корректности его атрибутов. Начальное состояние: Выполнен ВИ «Создать новое письмо» или ВИ «Создать ответ на письмо». Основной сценарий: 1. Пользователь выполняет команду отправки письма. 2. Программа проверяет, правильно ли заполнено поле «Адрес». 3. Если нет, программа сообщает об ошибке и отменяет отправку. Конец. 4. Если да, то программа проверяет, заполнено ли поле «Тема». 5. Если нет, программа выдает предупреждение, но не отменяет отправку. 6. Программа помещает письмо в папку «Исходящие» и отсылает его. 7. После отправки программа перемещает письмо в папку «Отправленные». Сценарий обработки ошибок:   Предусловие: на шаге 6 основного сценария происходит ошибка отправки письма (сбой сети и т. п.) 7. Программа сообщает об ошибке и предлагает сохранить текст письма в файл. 8. Если пользователь согласен сохранить текст, выполняется ВИ «Сохранить черновик в файл».


Слайд 41

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


Слайд 42

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


Слайд 43

Объекты проектирования —виды проектных требований Физическая структура (physical structure) Логическая структура (logical structure); Алгоритмы (algorithms); Структуры данных (data structures); Пользовательский интерфейс (user interface).


Слайд 44

Архитектурное и детальное проектирование Архитектурное проектирование = эскизное проектирование = концептуальное проектирование = проектирование в большом (design in large) Детальное проектирование = рабочее проектирование = техническое проектирование = проектирование в малом (design in small)


Слайд 45

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


Слайд 46

Декомпозиция проектируемой системы Основания декомпозиции: процедурное (алгоритмическое) и объектно-ориентированное. При процедурно-ориентированной декомпозиции выделяются процедуры, а при объектно-ориентированной — классы и объекты.


Слайд 47

Декомпозиция проектируемой системы При нисходящем проектировании (проектировании «сверху вниз», top-down design) проектирование начинается с верхнего уровня абстракции — представления системы как «черного ящика». При восходящем проектировании (проектировании «снизу вверх», bottom-up design) сразу выделяется множество необходимых элементов нижнего уровня реализации, затем над ними надстраивается уровень управления. При проектировании методом расширения ядра (проектировании «от центра») выделяется базовый процесс или объект (ядро), на котором основана вся система. Проектирование ведется одновременно «вниз» (для реализации ядра на низком уровне) и «вверх» (для использования ядра на верхнем уровне).


Слайд 48

Шаблоны проектирования То, что мы называем хаосом, — просто шаблоны, которые мы не распознали. То, что мы называем случайным, — шаблоны, которые мы не расшифровали. Чак Паланик Кристофер Александер (Christopher Alexander) в 1977 г. предложил язык описания шаблонов для плани­рования застройки городов и конструирования зданий. Широкое распространение шаблоны проектирования ПО получили после выхода в 1991 г. книги «банды четырёх» Эриха Гамма (Erich Gamma), Ричарда Хелма (Richard Helm), Ральфа Джонсона (Ralph Johnson) и Джона Влиссидеса (John Vlissides) «Приёмы объектно-ориентированного проектирования. Паттерны проектирования»


Слайд 49

Шаблоны проектирования Шаблон (паттерн) проектирования представляет собой формализованное описание часто встречающейся задачи проектирования удачное решение данной задачи рекомендации по применению этого решения в различных ситуациях. http://citforum.ru/SE/project/pattern/ http://c2.com/cgi/wiki?CategoryPattern


Слайд 50

Шаблоны проектирования 1. Шаблоны проектирования классов/объектов 1.1. Структурные шаблоны проектирования классов/объектов 1.2. Шаблоны проектирования поведения классов/объектов 1.3. Порождающие шаблоны проектирования 2. Архитектурные системные шаблоны 2.1. Структурные шаблоны 2.2. Шаблоны управления 2.2.1. Шаблоны централизованного управления 2.2.2. Шаблоны управления, основанные на событиях 2.2.3. Шаблоны взаимодействия с базой данных 3. Шаблоны интеграции корпоративных информационных систем 3.1. Структурные шаблоны интеграции 3.2. Шаблоны по методу интеграции 3.3. Шаблоны интеграции по типу обмена данными


Слайд 51

Анти-шаблоны (anti-patterns) http://www.antipatterns.com/briefing/ http://c2.com/cgi/wiki?AntiPatternsCatalog William J. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J. Mowbray AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. — John Wiley & Sons, 1998. — ISBN 0471197130


Слайд 52

Проектирование модулей 1. Модуль есть единица структуры исходного текста программы, оформляемая, как правило, в виде отдельного файла. 2. Модуль в программных проектах является единицей ком­пи­ля­ции, описания и администрирования. 3. Модуль имеет две логически различные части: интерфейс и реализацию. Интерфейс модуля есть набор описаний (прототипов) функций и данных модуля, доступных «извне» модуля. Реализация модуля есть собственно программный код функций и данных.


Слайд 53

Качество проектирования модулей Связность >> Зацепление


Слайд 54

Качество проектирования модулей Достаточность интерфейса Полнота интерфейса


Слайд 55

Проектирование интерфейса пользователя Для большинства пользователей интерфейс вашей системы и есть ваша система. Ребекка Райордан Когнитивная психология Физиология Лингвистика И др. Чтобы сделать хороший UI, необходимо понять, как человек думает, как общается, как манипулирует предметами, как запоминает и вспоминает, как догадывается, как учится, как видит, читает и пишет.


Слайд 56

Проектирование интерфейса пользователя Интерфейсом (interface) двух объектов называется система правил и средств, соответственно регламентирующих и обеспечивающих их взаимодействие. Интерфейс пользователя (user interface) — система правил и средств, соответственно регламентирующих и обеспечивающих взаимодействие пользователя и вычислительной системы в процессе выполнения данной программы.


Слайд 57

Классификации интерфейса пользователя По типу выводимой информации, или по типу формирования изображения, отличают символьный интерфейс пользователя (character user interface, CUI) и графический интерфейс пользователя (graphical user interface, GUI). По типу управления различают командный интерфейс и визуальный интерфейс. По активной стороне выделяют классический интерфейс и интерфейс «Мастеров» (Wizards).


Слайд 58

Характеристики интерфейса пользователя Дружественность (человечность) Предсказуемость (интуитивная понятность, очевидность). Простота Привлекательность (эстетичность) Целостность


Слайд 59

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


Слайд 60

Источники ошибок дизайна UI Отсутствие мотивации Работает и ладно И так сойдёт Не мои проблемы Да кого это волнует Ложная мотивация Сделаю так «круто», чтобы все ахнули Сделаю, как никто ещё не делал А мне вот так интересно попробовать Плохие примеры для подражания


Слайд 61

Примеры ошибок дизайна UI


Слайд 62

Примеры ошибок дизайна UI


Слайд 63

Примеры ошибок дизайна UI


Слайд 64

Примеры ошибок дизайна UI Вот так правильно:


Слайд 65

Примеры ошибок дизайна UI


Слайд 66

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


Слайд 67

Стандарты кодирования (1) Любой дурак способен писать код, который может понять компьютер. Хорошие программисты пишут код, который может понять человек. Мартин Фаулер Снижение зависимости от конкретных разработчиков Повышение сопровождаемости программ Повышение культуры программирования и снижение количества ошибок


Слайд 68

Стандарты кодирования (2) Структурирование текста Методы структурирования позволяют наглядно выявить соподчинённость конструкций и их группирование Разрежение текста Методы разрежения текста позволяют облегчить чтение за счёт дополнительных пробелов (горизонтальное разрежение) и пустых строк (вертикальное разрежение) Именование объектов Методы именования объектов включают системы именования переменных, типов, процедур и модулей Комментирование


Слайд 69

Стандарты кодирования (3) Делайте функции небольшими Функция должна делать только одно дело Функции должны быть функционально простыми Избегайте глобальных переменных Избегайте рекурсии


Слайд 70

Безопасное программирование Программирование есть соревнование между про­грам­мистами, делающими больше программ с все лучшей «защитой от дурака», и Вселенной, увеличивающей производство все более глупых идиотов. Похоже, что Вселенная пока выигрывает. Рич Кук Оптимистический подход Пессимистический подход пользователь очень часто выполняет неверные и даже недопустимые действия входные и выходные данные могут быть некорректными созданный программистами код заведомо содержит ошибки внешние программы и устройства постоянно подвержены сбоям


Слайд 71

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


Слайд 72

Безопасное программирование 1. Создавать «дуракоустойчивый» (foolproof) интерфейс. 2. Проверять корректность параметров, получаемых подпрограммой, даже если они заведомо должны быть правильными (проверка предусловий внутри подпрограммы). 3. Проверять корректность результатов, полученных в подпрограмме (проверка постусловий после вызова подпрограммы).


Слайд 73

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


Слайд 74

Дуракоустойчивый интерфейс 1. Делайте недоступными все элементы управления (кнопки, меню и т. д.), которые не должны в данный момент использоваться. 2. Где возможно, заменяйте поля клавиатурного ввода на специализированные компоненты: списки выбора (Combobox, Listbox), компоненты ввода чисел со стрелками инкремента/декремента (Spin edit), диалоги выбора файлов, папок, шрифтов и т. д. 3. В полях клавиатурного ввода широко используйте маски ввода, фильтрацию недопустимых символов и другие виды проверок корректности данных.


Слайд 75

Дуракоустойчивый интерфейс 4. При неверном вводе данных выводите пояснения, позволяющие пользователю понять свою ошибку. 5. Для сложных задач, требующих определённой последователь­ности действий, создавайте Мастера (Wizards). 6. Затрудняйте случайное выполнение опасных операций (назначайте им более сложные комбинации клавиш, требуйте подтверждения и т. д.) 7. Обеспечивайте возможность отмены действий (команды Undo, Cancel).


Слайд 76

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


Слайд 77

Тестирование Знайте, что быть экспертом — это больше, чем понимать, как система должна работать. Мастерство обретается исследованием того, почему она не работает. Брайан Редман Тестирование — оценка/исследование правильности работы программы или выявление ошибок в программе?


Слайд 78

Тестирование Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами и на оценку свойств ПО (IEEE 829-1983 Standard for Software Test Documentation). Ошибки: отклонения от спецификаций, при условии, что последние существуют и являются правильными, отклонения от требований «здравого смысла» (общесистемных требований), например, от законов математики и логики.


Слайд 79

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


Слайд 80

Объекты тестирования Исходные тексты программ Исполняемые модули (программы, библиотеки) Документация.


Слайд 81

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


Слайд 82

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


Слайд 83

Критерии качества тестирования Не иметь ошибок — это словно жить без смысла. Нет борьбы, нет и радости. Брайан Портер Критерии покрытия поведения (behavioral test coverage) Полнота функционального тестирования Критерии покрытия структуры (structural test coverage) Полнота покрытия операторов Полнота покрытия маршрутов Полнота покрытия данных


Слайд 84

Полнота покрытия маршрутов Сто триллионов (1014) маршрутов выполнения


Слайд 85

Основные виды тестирования Автономное и комплексное тестирование Тестирование белого и черного ящика Альфа- и бета-тестирование Функциональное тестирование Регрессионное тестирование Дымовое тестирование Нагрузочное тестирование Тестирование уязвимости


Слайд 86

Методы, используемые для тестирования Инспекция кода Многократная разработка Метод эквивалентных разбиений Метод анализа граничных значений


Слайд 87

Метод эквивалентных разбиений X: [0;100] Поиск подстроки s в строке S Один класс допустимых значений [0;100] и два — недопустимых: (–?;0) и (100;+?) Минимально допустимый набор классов: {s есть в S} и {s нет в S}


Слайд 88

Метод анализа граничных значений [0;100]: {–0,00001; 0; 0,00001; 99,99999; 100; 100,00001} s в S: длина(s) = длина(S)–1; длина(s) = длина(S); длина(s) = длина(S)+1; длина(s и/или S) = 0; длина(s и/или S) = 1; s = nil; S = nil.


Слайд 89

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


Слайд 90

Организация тестирования Задачи подбор команды тестирования разработка регламента тестирования организация разработки тестов создание сценариев тестирования создание тестовых данных контроль за исполнением регламента. Специалисты Тест-инженер (test engineer): наиболее квалифицированный специалист, который владеет навыками планирования тестирования, разработки и проведения тестов, а также понимает предметную область Тестер, тестировщик (test technician, test specialist) менее квалифицированный специалист, который главным образом занимается выполнением тестов


Слайд 91

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


Слайд 92

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


Слайд 93

Некоторые интересные факты Есть два способа написания программ без ошибок; но работает только третий. Для исправления проблем, выявленных при сопровождении продукта, программисты по статистике тратят до 60 % времени, пытаясь понять документацию и логику программы. Фирмой IBM установлено, что в среднем одна ранее не обнаруженная ошибка появляется в каждых 100 операторах программы Большинство ошибок содержится в сопряжениях модулей и операторах ввода-вывода После того как проведено тестирование отдельно каждого модуля, и они объединяются в систему, в 90 % всех новых модулей и в 15 % старых необходимо вносить изменения При этом приблизительно в 15 % новых модулей и 6 % старых следует внести более 10 изменений


Слайд 94

Документирование Документация как секс: если она качественная, это очень хорошо; если плоха, — это лучше, чем ничего. Единая система программной документации (ЕСПД) ГОСТ Р ИСО/МЭК 15910-2002 (ISO/IEC 15910-99) Программная и эксплуатационная документация может использоваться для изготовления и сопровождения программного изделия, для его тестирования (испытания), для его эксплуатации. Документирование должно начинаться одновременно с разработкой продукта или даже раньше


Слайд 95

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


Слайд 96

Терминология (1) a) применять общие и нетехнические термины в соответствии с их определениями, установленными в общих словарях; b) создавать глоссарии (словники), содержащие: 1) определения всех специфических и неизвестных терминов, 2) виды и определения всех обозначений и сокращений, 3) толкования непривычного использования слов, применение имен существительных в качестве наречий, 4) библиографию специализированных словарей и стандартов; c) специальная терминология должна быть основана на национальных или международных терминологических стандартах, общепризнанных словарях или согласованных глоссариях; d) каждое сокращение должно быть расшифровано при первом его появлении в тексте основной части документа;


Слайд 97

Терминология (2) e) каждый термин должен одинаково трактоваться в документе, диалоговой информации и системной библиотеке; f) составные выражения (например, «ввод данных [data input]») должны иметь одно смысловое значение во всей документации; g) составные выражения не должны содержать более трех слов; h) одно и то же слово не должно использоваться для различных частей речи; i) все специфические и специальные термины должны использоваться в соответствующем контексте; j) термины, вводимые вне соответствующего контекста, например наименования клавиш или команды, должны быть определены в глоссарии


Слайд 98

Физические факторы a) сокращения нецелесообразно использовать только для экономии места; b) предусмотреть необходимые места для простановки соответствующих значений, например цены; c) следует использовать стандартные графические инструментальные средства (пакеты) и избегать применения вклеек; d) избегать внесения поясняющего текста в рисунки; e) следует использовать графические символы, имеющие общепринятое смысловое значение; f) по возможности вместо словесного пояснения использовать графические изображения.


Слайд 99

Диалоговая информация a) при наличии обратной связи с разработчиками программных средств следует обеспечить выделение диалоговой информации (текстов и сообщений) из логики программы; b) каждый блок текста или сообщение должны иметь индивидуальное идентификационное обозначение с указанием соответствующей классификационной группы данного текста или сообщения; c) конкретное программное средство не должно ориентироваться на длину, формат или расположение экранных полей ввода-вывода (input and output fields); d) для каждого понятия следует использовать отдельное сообщение. Сообщения не должны быть надуманными; e) переменные в сообщении должны содержать только непереводимую информацию, например ключевые слова и коды возврата; f) из предложений не следует исключать предлоги в целях экономии места.


Слайд 100

Культурные факторы (1) a) иллюстративные материалы (например, лица, животные и звуки речи) должны быть независимыми от национальных культурных особенностей; b) следует избегать использования примеров, связанных со специфическими национальными традициями или особенностями (например, праздниками, банковским делом, зарплатой, спортом и т.д.); c) в тексте и иллюстрациях следует избегать использования идиоматических выражений, присущих национальному языку документатора; d) следует избегать использования юмористических выражений, особенно каламбуров. e) следует осторожно использовать иронические выражения;


Слайд 101

Культурные факторы (2) f) необходимо избегать использования сленговых, жаргонных и простонародных выражений; g) не должны использоваться упоминания первых лиц государства; h) не следует выражать даты только в числовом виде. Месяц всегда должен быть написан полностью (например, 28 июля 1991); i) обычно следует использовать двумерные представления, если международные соглашения не требуют иного (например, для автошин, водопроводов, гвоздей и фотопленки); j) когда метрические величины располагаются вместе с величинами в других системах измерения, из контекста должно быть понятно, какая из величин относится к соответствующей системе измерений.


Слайд 102

Выпуск Основные этапы готовности продукта: Реализация базовых функций множество возможностей ещё отсутствуют, однако все базовые уже реализованы 2. Альфа-версия завершенный, но ещё полный ошибок продукт имеются практически все её функции, однако некоторые могут работать крайне нестабильно интерфейс и документация находятся в стадии доработки 3. Бета-версия практически законченный продукт, в котором разработчики выполнили своими силами всё возможное тестирование 4. Релиз приёмо-сдаточные испытания


Слайд 103

Приёмо-сдаточные испытания Общее планирование испытаний : Разработка общей стратегии испытаний системы Календарный график проведения испытаний планирование ресурсов планирование видов испытаний планирование состава комиссии для каждого испытания Детальное планирование испытаний Выявить условия, демонстрирующие функционирование системы с точки зрения пользователей Подготовить демонстрационные тесты подготовить демонстрационные данные подготовить демонстрационные сценарии Описать программу и методику испытаний


Слайд 104

Контрольные бланки испытания


Слайд 105

Внедрение Испытания Исправления Опытная эксплуатация Промышленная эксплуатация


Слайд 106

Оценка качества ПО Измеряй то, что измеримо, и делай измеримым то, что нельзя измерить. Галилео Галилей Квалиметрия: дисциплина, изучающая количественную оценку качества теоретическая: математические модели прикладная: конкретные видов объектов географическая педагогическая …


Слайд 107

Понятие качества Качество программы (quality) — весь объём признаков и характеристик программы, который относится к её способности удовлетворять установленным или предполагаемым потребностям. Уровень качества функционирования (level of performance) — степень, в которой удовлетворяются потребности, представленные конкретным набором значений для характеристик качества.


Слайд 108

Свойства программного средства Функциональные свойства Отражают возможности и специфику применения программы и обусловливают степень её соответствия своему целевому назначению. Они характеризуют программу с точки зрения того, как в действительности она выполняется. Конструктивные свойства Характеризуют программу с точки зрения того, как в действительности она сконструирована, устроена. Более или менее не зависят от её функциональных возможностей и назначения.


Слайд 109

Методы оценки свойств ПО ГОСТ 28195-89 «Оценка качества программных средств» по способам получения информации измерительный, регистрационный, органолептический, расчётный; по источникам получения информации традиционный, экспертный, Социологический.


Слайд 110

Номенклатура показателей качества ГОСТ Р ИСО/МЭК 9126-93. «Оценка программной продукции. Характеристики качества и руководства по их применению» Функциональные возможности (Functionality) Надёжность (Reliability) Практичность (Usability) Эффективность (Efficiencies) Сопровождаемость (Maintainability) Мобильность (Portability)


Слайд 111

Описание методов программной инженерии «Essence: Kernel and Language for Software Engineering Methods» («Основы: ядро и язык методов программной инженерии») — стандарт OMG 2013 г., созданный SEMAT. OMG (Object Management Group): консорциум по стандартам в компьютерной индустрии, основан в 1989 г. SEMAT (Software Engineering Method and Theory): консорциум по унификации теории программной инженерии, основан в 2009 г.


Слайд 112

Ядро (Kernel) Ядро программной инженерии (Software Engineering Kernel) — минимальный набор определений, который выражает суть программной инженерии способом, независимым от конкретных практик. Альфы (Alphas) — ключевые понятия (essential things to work with). Типовые деятельности (Activity Spaces) — ключевые типы деятельности (essential things to do). Компетенции (Competencies) — ключевые способности (the abilities needed).


Слайд 113

Ядро: Альфа Ключевой элемент, с помощью оценки состояния которого которого можно оценить прогресс и успешность проекта. An essential element of the software engineering endeavor that is relevant to an assessment of the progress and health of the endeavor. Alpha is an acronym for an Abstract-Level Progress Health Attribute.


Слайд 114

Ядро: Типовая деятельность Заготовка (placeholder) для типовой деятельности в проекте. Называет, что должно делаться, но не предписывает как именно. A placeholder for something to be done in the software engineering endeavor. A placeholder may consist of zero to many activities.


Слайд 115

Ядро: Компетенция Характеристика представителя стейкхолдера или члена команды с точки зрения способности к определённой работе. A characteristic of a stakeholder or team member that reflects the ability to do work.


Слайд 116

Альфы


Слайд 117

Альфы


Слайд 118

Альфы (область клиента) 1. Opportunity: The set of circumstances that makes it appropriate to develop or change a software system. 2. Stakeholders: The people, groups, or organizations who affect or are affected by a software system.


Слайд 119

Альфы (область решения) 3. Requirements: What the software system must do to address the opportunity and satisfy the stakeholders. 4. Software System: A system made up of software, hardware, and data that provides its primary value by the execution of the software.


Слайд 120

Альфы (область предпринятия) 5. Work: Activity involving mental or physical effort done in order to achieve a result. 6. Team: The group of people actively engaged in the development, maintenance, delivery and support of a specific software system. 7. Way-of-Working: The tailored set of practices and tools used by a team to guide and support their work.


Слайд 121

Стейкхолдеры: состояния


Слайд 122

Возможности: состояния


Слайд 123

Требования: состояния


Слайд 124

Система: состояния


Слайд 125

Команда: состояния


Слайд 126

Работа: состояния


Слайд 127

Технология работы: состояния


Слайд 128


Слайд 129

Типовые деятельности


Слайд 130

Компетенции


Слайд 131


×

HTML:





Ссылка: