США водопроводчик учится около 8 лет. И это чтобы починить мой чёртов унитаз. Ну, и сколько же вы должны учиться, чтобы вам позволили создавать программы для самолетов с сотнями людей на борту?
Джеймс Коплиен
- Главная
- Разное
- Дизайн
- Бизнес и предпринимательство
- Аналитика
- Образование
- Развлечения
- Красота и здоровье
- Финансы
- Государство
- Путешествия
- Спорт
- Недвижимость
- Армия
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Технологии программированияSoftware engineering презентация
Содержание
- 1. Технологии программированияSoftware engineering
- 2. Литература, вопросы к экзамену http://metod.ce.cctpu.edu.ru/edu/df/se/ Брауде Э.
- 3. Виды обеспечения ВС математическое: методы, алгоритмы; лингвистическое:
- 4. Software engineering Применение систематического, упорядоченного, измеримого подхода
- 5. Кризис ПО
- 6. в 1995 г. ожидалось, что только
- 7. Сложность разработки ПО Управление сложностью — суть
- 8. Жизненный цикл программного продукта ISO/IEC 12207:2008 «System
- 9. Жизненный цикл Жизненный цикл (ЖЦ) программного средства
- 10. Группы процессов ЖЦ a) процессы соглашения —
- 11. Процессы соглашения Поставка Приобретение
- 12. Процессы организационного обеспечения проекта a) процесс менеджмента
- 13. Процессы проекта Процессы менеджмента проекта процесс планирования
- 14. Технические процессы a) определение требований правообладателей
- 15. Процессы реализации программных средств а) процесс анализа
- 16. Процессы поддержки программных средств a) процесс менеджмента
- 17. Процессы повторного применения программных средств a) процесс
- 18. Модели разработки Водопадная (каскадная, последовательная) Эволюционная (итеративная, инкрементальная)
- 19. Водопадная (waterfall)
- 20. Эволюционная (IID)
- 21. Методологии разработки Последовательность работ и их содержание;
- 22. Методологии разработки Единая система программной документации (ЕСПД)
- 23. Выбор и адаптация методологии Масштаб проекта Надёжность
- 24. Управление проектом Управлять программистами — это всё
- 25. Основные задачи Планирование (planning) Контроль исполнения (tracking and oversight)
- 26. Планирование Структура декомпозиции работ (work breakdown structure,
- 27. Планирование Железный треугольник (треугольник возможностей):
- 28. Управление конфигурацией Как организовать согласованную коллективную работу
- 29. Управление конфигурацией Конфигурация в данном контексте понимается
- 30. Задачи Определить что надо хранить (выполнить конфигурационную
- 31. Внедрение и управление Внедрение управления конфигурацией: выбор
- 32. Оценка качества процесса разработки Насколько «правильно» данная
- 33. CMM (Capability Maturity Model)
- 34. CMM 1. Начальный уровень (Initial level) В организации
- 35. CMMI В 2000 г. SEI предложил сменить
- 36. Анализ требований Анализ требований представляет собой исследование
- 37. Основные работы при анализе Исходная постановка задачи
- 38. Техническое задание ГОСТ 19.201-78. Единая система программной
- 39. Варианты использования Автор: Айвар Якобсон (Ivar Jacobson) Вариант
- 40. Варианты использования Краткий (brief) ВИ Бессистемный
- 41. Варианты использования Название: Отправить электронное письмо. Цель:
- 42. Виды применения ВИ Как средство фиксации
- 43. Проектирование Хороший проектировщик обязан полагаться на
- 44. Объекты проектирования —виды проектных требований Физическая
- 45. Архитектурное и детальное проектирование Архитектурное проектирование
- 46. Архитектура Архитектура состоит из всех важных проектных
- 47. Декомпозиция проектируемой системы Основания декомпозиции: процедурное (алгоритмическое)
- 48. Декомпозиция проектируемой системы При нисходящем проектировании (проектировании
- 49. Шаблоны проектирования То, что мы называем хаосом,
- 50. Шаблоны проектирования Шаблон (паттерн) проектирования представляет собой
- 51. Шаблоны проектирования 1. Шаблоны проектирования классов/объектов 1.1.
- 52. Анти-шаблоны (anti-patterns) http://www.antipatterns.com/briefing/ http://c2.com/cgi/wiki?AntiPatternsCatalog William J.
- 53. Проектирование модулей 1. Модуль есть единица структуры
- 54. Качество проектирования модулей Связность >> Зацепление
- 55. Качество проектирования модулей Достаточность интерфейса Полнота интерфейса
- 56. Проектирование интерфейса пользователя Для большинства пользователей интерфейс
- 57. Проектирование интерфейса пользователя Интерфейсом (interface) двух объектов
- 58. Классификации интерфейса пользователя По типу выводимой информации,
- 59. Характеристики интерфейса пользователя Дружественность (человечность) Предсказуемость (интуитивная понятность, очевидность). Простота Привлекательность (эстетичность) Целостность
- 60. Типичные ошибки дизайна UI Непредсказуемость, неэстетичность, сложность,
- 61. Источники ошибок дизайна UI Отсутствие мотивации Работает
- 62. Примеры ошибок дизайна UI
- 63. Примеры ошибок дизайна UI
- 64. Примеры ошибок дизайна UI
- 65. Примеры ошибок дизайна UI Вот так правильно:
- 66. Примеры ошибок дизайна UI
- 67. Программирование Если отладка — процесс удаления ошибок,
- 68. Стандарты кодирования (1) Любой дурак способен писать
- 69. Стандарты кодирования (2) Структурирование текста Методы структурирования
- 70. Стандарты кодирования (3) Делайте функции небольшими Функция
- 71. Безопасное программирование Программирование есть соревнование между программистами,
- 72. Безопасное программирование Подход: встраивать проверки, обнаруживающие ошибки
- 73. Безопасное программирование 1. Создавать «дуракоустойчивый» (foolproof) интерфейс. 2.
- 74. Безопасное программирование 4. Проверять результаты взаимодействия с
- 75. Дуракоустойчивый интерфейс 1. Делайте недоступными все элементы
- 76. Дуракоустойчивый интерфейс 4. При неверном вводе данных
- 77. Оптимизация программы Неважно, насколько эффективно работает программа,
- 78. Тестирование Знайте, что быть экспертом — это
- 79. Тестирование Тестирование — это процесс анализа ПО,
- 80. Основные понятия Тест: эксперимент, выполняемый над программой,
- 81. Объекты тестирования Исходные тексты программ Исполняемые модули (программы, библиотеки) Документация.
- 82. Три принципа тестирования Необходимо создавать тесты, которые
- 83. Основные проблемы организации тестирования Нередко отсутствует эталон,
- 84. Критерии качества тестирования Не иметь ошибок —
- 85. Полнота покрытия маршрутов Сто триллионов (1014) маршрутов выполнения
- 86. Основные виды тестирования Автономное и комплексное тестирование
- 87. Методы, используемые для тестирования Инспекция кода Многократная разработка Метод эквивалентных разбиений Метод анализа граничных значений
- 88. Метод эквивалентных разбиений X: [0;100] Поиск подстроки
- 89. Метод анализа граничных значений [0;100]: {–0,00001; 0;
- 90. Средства автоматизации тестирования Системы поддержки автоматизированного модульного
- 91. Организация тестирования Задачи подбор команды тестирования разработка
- 92. Классификация ошибок по серьёзности Если вы с
- 93. Классификация ошибок по видам деятельности, которые привели
- 94. Некоторые интересные факты Есть два способа написания
- 95. Документирование Документация как секс: если она
- 96. Примеры эксплуатационных документов Руководство пользователя — сведения
- 97. Терминология (1) a) применять общие и нетехнические
- 98. Терминология (2) e) каждый термин должен одинаково
- 99. Физические факторы a) сокращения нецелесообразно использовать только
- 100. Диалоговая информация a) при наличии обратной связи
- 101. Культурные факторы (1) a) иллюстративные материалы (например,
- 102. Культурные факторы (2) f) необходимо избегать использования
- 103. Выпуск Основные этапы готовности продукта: Реализация базовых
- 104. Приёмо-сдаточные испытания Общее планирование испытаний : Разработка
- 105. Контрольные бланки испытания
- 106. Внедрение Испытания Исправления Опытная эксплуатация Промышленная эксплуатация
- 107. Оценка качества ПО Измеряй то, что измеримо,
- 108. Понятие качества Качество программы (quality) — весь
- 109. Свойства программного средства Функциональные свойства Отражают
- 110. Методы оценки свойств ПО ГОСТ 28195-89 «Оценка
- 111. Номенклатура показателей качества ГОСТ Р ИСО/МЭК 9126-93.
- 112. Описание методов программной инженерии «Essence: Kernel and
- 113. Ядро (Kernel) Ядро программной инженерии (Software Engineering
- 114. Ядро: Альфа Ключевой элемент, с помощью оценки
- 115. Ядро: Типовая деятельность Заготовка (placeholder) для типовой
- 116. Ядро: Компетенция Характеристика представителя стейкхолдера или члена
- 117. Альфы
- 118. Альфы
- 119. Альфы (область клиента) 1. Opportunity: The
- 120. Альфы (область решения) 3. Requirements: What
- 121. Альфы (область предпринятия) 5. Work: Activity
- 122. Стейкхолдеры: состояния
- 123. Возможности: состояния
- 124. Требования: состояния
- 125. Система: состояния
- 126. Команда: состояния
- 127. Работа: состояния
- 128. Технология работы: состояния
- 130. Типовые деятельности
- 131. Компетенции
Литература, вопросы к экзамену http://metod.ce.cctpu.edu.ru/edu/df/se/ Брауде Э. Технология разработки программного обеспечения. — СПб.: «Питер», 2004. — 655 с.: ил. Брукс Ф. Мифический человеко-месяц или как создаются программные си-стемы: Пер. с англ.
Слайд 1Технологии программирования
Software engineering
Евгений Александрович Мирошниченко
доцент кафедры вычислительной техники, к. т. н.
В
Слайд 2Литература, вопросы к экзамену
http://metod.ce.cctpu.edu.ru/edu/df/se/
Брауде Э. Технология разработки программного обеспечения. — СПб.:
«Питер», 2004. — 655 с.: ил.
Брукс Ф. Мифический человеко-месяц или как создаются программные си-стемы: Пер. с англ. — СПб.: Символ-Плюс, 1999. — 304 с.: ил.
Орлов С.А. Технологии разработки программного обеспечения, 2-е изд. — СПб.: "Питер", 2003. — 473 с.: ил.
Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. — СПб.: Питер, 2002. — 496 с.: ил.
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб.: Питер, 2001. — 368 с.: ил.
Дастин Э., Рэшка Дж., Пол Дж. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация: Пер. с англ. — М: Лори, 2003. — 567 с.: ил.
Йордан Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. — М.: Лори, 2003. — 255 с.
Брукс Ф. Мифический человеко-месяц или как создаются программные си-стемы: Пер. с англ. — СПб.: Символ-Плюс, 1999. — 304 с.: ил.
Орлов С.А. Технологии разработки программного обеспечения, 2-е изд. — СПб.: "Питер", 2003. — 473 с.: ил.
Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. — СПб.: Питер, 2002. — 496 с.: ил.
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб.: Питер, 2001. — 368 с.: ил.
Дастин Э., Рэшка Дж., Пол Дж. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация: Пер. с англ. — М: Лори, 2003. — 567 с.: ил.
Йордан Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. — М.: Лори, 2003. — 255 с.
Слайд 3Виды обеспечения ВС
математическое: методы, алгоритмы;
лингвистическое: языки, способы взаимодействия;
информационное: данные;
программное: программы;
техническое: аппаратные
средства;
методическое: документы, методики;
организационное: правила, регламенты, процедуры.
Прошедшая испытания программа или программная система, полностью готовая для продажи (поставки) и снабженная всей необходимой документацией, называется программным продуктом, изделием или средством (software product, production program).
методическое: документы, методики;
организационное: правила, регламенты, процедуры.
Прошедшая испытания программа или программная система, полностью готовая для продажи (поставки) и снабженная всей необходимой документацией, называется программным продуктом, изделием или средством (software product, production program).
Слайд 4Software engineering
Применение систематического, упорядоченного, измеримого подхода к разработке, использованию и сопровождению
ПО, то есть использование инженерного искусства в ПО.
Создание подходов п. (1)
Создание подходов п. (1)
Слайд 6
в 1995 г. ожидалось, что только 9 % проектов, выполняемых крупными компаниями,
будут завершены в срок и без превышения запланированного бюджета; 52 % проектов должны были стоить в среднем 189 % от их первоначально оцененной стоимости; в то же время 31 % всех проектов вообще ожидало приостановление или полное прекращение, причем затраты на них — ничем не компенсируемые убытки — оценивались ни много ни мало в 81 млрд долл.
Через десятилетие, в 2004 г. 18 % проектов провалились, 53 % (более половины!) — не уложились в заданный бюджет или сроки, только 29 % были признаны успешными.
Через десятилетие, в 2004 г. 18 % проектов провалились, 53 % (более половины!) — не уложились в заданный бюджет или сроки, только 29 % были признаны успешными.
Слайд 7Сложность разработки ПО
Управление сложностью — суть программирования.
Брайан Керниган
Сложность предметной области
Внутренняя сложность
программ
Отсутствие хороших способов представления больших систем
Трудности управления процессом разработки
Изменение требований к программе в процессе её разработки
Отсутствие хороших способов представления больших систем
Трудности управления процессом разработки
Изменение требований к программе в процессе её разработки
Слайд 8Жизненный цикл программного продукта
ISO/IEC 12207:2008 «System and software engineering — Software
life cycle processes»
ГОСТ Р ИСО/МЭК 12207—2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
ГОСТ Р ИСО/МЭК 12207—2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
Слайд 9Жизненный цикл
Жизненный цикл (ЖЦ) программного средства есть совокупность взаимосвязанных процессов создания
и последовательного изменения его состояния — от формирования исходных требований до окончания эксплуатации.
Процесс ЖЦ — конкретный вид деятельности, систематически выполняющийся для решения определённых задач ЖЦ.
Процесс ЖЦ — конкретный вид деятельности, систематически выполняющийся для решения определённых задач ЖЦ.
Слайд 10Группы процессов ЖЦ
a) процессы соглашения — 2
b) процессы организационного обеспечения проекта
— 5
c) процессы проекта — 7;
d) технические процессы — 11
e) процессы реализации программных средств — 7
f) процессы поддержки программных средств — 8
g) процессы повторного применения программных средств — 3
c) процессы проекта — 7;
d) технические процессы — 11
e) процессы реализации программных средств — 7
f) процессы поддержки программных средств — 8
g) процессы повторного применения программных средств — 3
Слайд 12Процессы организационного обеспечения проекта
a) процесс менеджмента модели жизненного цикла;
b) процесс менеджмента
инфраструктуры;
c) процесс менеджмента портфеля проектов;
d) процесс менеджмента людских ресурсов;
e) процесс менеджмента качества.
c) процесс менеджмента портфеля проектов;
d) процесс менеджмента людских ресурсов;
e) процесс менеджмента качества.
Слайд 13Процессы проекта
Процессы менеджмента проекта
процесс планирования проекта;
процесс управления и оценки проекта.
Процессы поддержки
проекта
процесс менеджмента решений;
процесс менеджмента рисков;
процесс менеджмента конфигурации;
процесс менеджмента информации;
процесс измерений.
процесс менеджмента решений;
процесс менеджмента рисков;
процесс менеджмента конфигурации;
процесс менеджмента информации;
процесс измерений.
Слайд 14Технические процессы
a) определение требований правообладателей
b) анализ системных требований
c) проектирование архитектуры
системы
d) процесс реализации
e) процесс комплексирования системы
f) процесс квалификационного тестирования системы
g) процесс инсталляции программных средств
h) процесс поддержки приемки программных средств
i) процесс функционирования программных средств
j) процесс сопровождения программных средств
k) процесс изъятия из обращения программных средств
d) процесс реализации
e) процесс комплексирования системы
f) процесс квалификационного тестирования системы
g) процесс инсталляции программных средств
h) процесс поддержки приемки программных средств
i) процесс функционирования программных средств
j) процесс сопровождения программных средств
k) процесс изъятия из обращения программных средств
Слайд 15Процессы реализации программных средств
а) процесс анализа требований к программным средствам;
b) процесс
проектирования архитектуры программных средств;
c) процесс детального проектирования программных средств;
d) процесс конструирования программных средств;
e) процесс комплексирования программных средств;
f) процесс квалификационного тестирования программных средств
c) процесс детального проектирования программных средств;
d) процесс конструирования программных средств;
e) процесс комплексирования программных средств;
f) процесс квалификационного тестирования программных средств
Слайд 16Процессы поддержки программных средств
a) процесс менеджмента документации программных средств;
b) процесс менеджмента
конфигурации программных средств;
c) процесс обеспечения гарантии качества программных средств;
d) процесс верификации программных средств;
e) процесс валидации программных средств;
f) процесс ревизии программных средств;
g) процесс аудита программных средств;
h) процесс решения проблем в программных средствах.
c) процесс обеспечения гарантии качества программных средств;
d) процесс верификации программных средств;
e) процесс валидации программных средств;
f) процесс ревизии программных средств;
g) процесс аудита программных средств;
h) процесс решения проблем в программных средствах.
Слайд 17Процессы повторного применения программных средств
a) процесс проектирования доменов;
b) процесс менеджмента повторного
применения активов;
c) процесс менеджмента повторного применения программ.
c) процесс менеджмента повторного применения программ.
Слайд 18Модели разработки
Водопадная (каскадная, последовательная)
Эволюционная (итеративная, инкрементальная)
Слайд 21Методологии разработки
Последовательность работ и их содержание;
артефакты, которые необходимо создавать в процессе
работы: документы, диаграммы, исходные тексты и т. д.;
организацию команды и ролевую ответственность специалистов;
лучшие практики (best practices), позволяющие максимально эффективно воспользоваться методологией и её моделью
организацию команды и ролевую ответственность специалистов;
лучшие практики (best practices), позволяющие максимально эффективно воспользоваться методологией и её моделью
Слайд 22Методологии разработки
Единая система программной документации (ЕСПД)
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
Agile-методологии
Экстремальное программирование (eXtreme Programming, XP)
Adaptive Software Development (ASD), Lean Development, SCRUM, Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal Clear
Слайд 23Выбор и адаптация методологии
Масштаб проекта
Надёжность программы
Распределённость команды
Новизна проекта
Требования заказчика
Долговечность проекта
Слайд 24Управление проектом
Управлять программистами — это всё равно, что пытаться пасти котов.
Грег
Сетл
Проект = Design = модель будущей системы
Проект = Project = комплекс действий, направленных на создание продукта или услуги
Проект = Design = модель будущей системы
Проект = Project = комплекс действий, направленных на создание продукта или услуги
Слайд 26Планирование
Структура декомпозиции работ (work breakdown structure, WBS), или иерархическая структура работ
Исполнители
Время
Планирование
= отображение списка работ на список исполнителей во времени.
Слайд 27Планирование
Железный треугольник (треугольник возможностей):
Если жёстко задан (неизменяем) какой-то один из этих
параметров, то можно варьировать одним из двух оставшихся. Последний неизбежно будет функцией двух первых.
Время
Деньги (ресурсы, люди)
Качество (возможности, требования)
Слайд 28Управление конфигурацией
Как организовать согласованную коллективную работу множества людей с одними и
теми же файлами и документами;
как хранить версии всех файлов (текстов программ, электронных документов), чтобы предотвратить потерю или порчу информации и обеспечить откат к нужной версии;
как в точности определить, кто и какие изменения внёс.
как хранить версии всех файлов (текстов программ, электронных документов), чтобы предотвратить потерю или порчу информации и обеспечить откат к нужной версии;
как в точности определить, кто и какие изменения внёс.
Слайд 29Управление конфигурацией
Конфигурация в данном контексте понимается как совокупность всей информации о
проекте.
Конфигурация физически распределена по файлам и документам проекта (состав и содержание всех материалов проекта и образует текущую конфигурацию).
Как правило, это исходные тексты и бинарные файлы разрабатываемой программы и вся сопроводительная и организационная документация.
Конфигурация физически распределена по файлам и документам проекта (состав и содержание всех материалов проекта и образует текущую конфигурацию).
Как правило, это исходные тексты и бинарные файлы разрабатываемой программы и вся сопроводительная и организационная документация.
Слайд 30Задачи
Определить что надо хранить (выполнить конфигурационную идентификацию);
организовать хранение всей истории изменений;
организовать
согласованность внесения изменений (контроль конфигурации);
организовать хранение моментальных снимков (версий) конфигурации, то есть согласованных состояний проекта в некоторые важные моменты времени.
организовать хранение моментальных снимков (версий) конфигурации, то есть согласованных состояний проекта в некоторые важные моменты времени.
Слайд 31Внедрение и управление
Внедрение управления конфигурацией:
выбор и внедрение системы управления версиями (version
control system);
разработка организационного обеспечения (регламента).
Дальнейшее управление:
управление составом конфигурации;
управление правами доступа к системе управления версиями;
разрешение проблем;
резервное копирование (backup).
разработка организационного обеспечения (регламента).
Дальнейшее управление:
управление составом конфигурации;
управление правами доступа к системе управления версиями;
разрешение проблем;
резервное копирование (backup).
Слайд 32Оценка качества процесса разработки
Насколько «правильно» данная организация производит продукцию?
ISO серии 9000
CMM
(Capability Maturity Model) — модель зрелости возможностей
ISO/IEC 15504: Information Technology — Software Process Assessment = SPICE (Software Process Improvement and Capability dEtermination)
ISO/IEC 15504: Information Technology — Software Process Assessment = SPICE (Software Process Improvement and Capability dEtermination)
Слайд 34CMM
1. Начальный уровень (Initial level)
В организации царит анархия при разработке, нет четких
процессов управления и четких инженерных процессов. Могут существовать стандарты и инструкции, но им никто не следует. Неравномерность процесса разработки — наличие затиший и авралов в работе
2. Повторяемый уровень (Repeatable level)
Внедрено управление проектами, управление конфигурацией. Полная зависимость от конкретных личностей сохраняется, а организация имеет сильную тенденцию «сползания» к начальному уровню.
3. Определённый уровень (Defined level)
Процессы управления интегрированы с инженерными процессами (методологий разработки) в единый стандартный документированный программный процесс. Нет деградации процесса в стрессовых ситуациях
4. Управляемый уровень (Managed level)
Устанавливаются количественные показатели качества, которые собираются с помощью специального измерительного инструментария и оперативно анализируются менеджерами. Достигается полное управление проектами и предсказуемость программного процесса и качества программ.
5. Оптимизирующий уровень (Optimizing level)
Организация постоянно и целенаправленно занимается улучшением существующих процессов, и делает это полностью контролируемым образом. Организация нацелена на предупреждение дефектов (defect prevention).
2. Повторяемый уровень (Repeatable level)
Внедрено управление проектами, управление конфигурацией. Полная зависимость от конкретных личностей сохраняется, а организация имеет сильную тенденцию «сползания» к начальному уровню.
3. Определённый уровень (Defined level)
Процессы управления интегрированы с инженерными процессами (методологий разработки) в единый стандартный документированный программный процесс. Нет деградации процесса в стрессовых ситуациях
4. Управляемый уровень (Managed level)
Устанавливаются количественные показатели качества, которые собираются с помощью специального измерительного инструментария и оперативно анализируются менеджерами. Достигается полное управление проектами и предсказуемость программного процесса и качества программ.
5. Оптимизирующий уровень (Optimizing level)
Организация постоянно и целенаправленно занимается улучшением существующих процессов, и делает это полностью контролируемым образом. Организация нацелена на предупреждение дефектов (defect prevention).
Слайд 35CMMI
В 2000 г. SEI предложил сменить CMM новой, улучшенной моделью —
CMMI (Capability Maturity Model for Integration).
CMMI фактически является обобщением CMM, поскольку рассматривает не только процессы разработки, как CMM, но и другие процессы ЖЦ (приобретение, сопровождение и т. д.)
Часто используется сокращение CMM/CMMI.
CMMI фактически является обобщением CMM, поскольку рассматривает не только процессы разработки, как CMM, но и другие процессы ЖЦ (приобретение, сопровождение и т. д.)
Часто используется сокращение CMM/CMMI.
Слайд 36Анализ требований
Анализ требований представляет собой исследование предметной области, выявление роли и
места будущей программной системы, её основных функций и характеристик.
Формальным результатом анализа является спецификация требований (requirements/product/preliminary specification) в том или ином виде.
Формальным результатом анализа является спецификация требований (requirements/product/preliminary specification) в том или ином виде.
Слайд 37Основные работы при анализе
Исходная постановка задачи
Сбор и исследование информации
Данные о предметной
области в целом.
Данные о существующих аналогах.
Данные о специфике предприятия-заказчика:
специфика бизнес-процессов организации;
данные об унаследованном ПО (legacy software);
используемое аппаратное обеспечение;
политика безопасности организации;
уровень квалификации персонала.
Выбор приоритетных критериев качества
Определение входных, хранимых и выходных данных
Формализация требований, их описание
Данные о существующих аналогах.
Данные о специфике предприятия-заказчика:
специфика бизнес-процессов организации;
данные об унаследованном ПО (legacy software);
используемое аппаратное обеспечение;
политика безопасности организации;
уровень квалификации персонала.
Выбор приоритетных критериев качества
Определение входных, хранимых и выходных данных
Формализация требований, их описание
Слайд 38Техническое задание
ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к
содержанию и оформлению
ГОСТ 34.602-89 Информационная технология. Техническое задание на создание автоматизированной системы
ГОСТ 34.602-89 Информационная технология. Техническое задание на создание автоматизированной системы
Слайд 39Варианты использования
Автор: Айвар Якобсон (Ivar Jacobson)
Вариант использования — это формальное описание взаимодействия
системы и пользователя при решении конкретной задачи. Каждый ВИ нацелен на конкретную бизнес-цель (конкретную задачу).
«Usage scenario» →
«usage case»→
«use case»
«Usage scenario» →
«usage case»→
«use case»
Слайд 40Варианты использования
Краткий (brief) ВИ
Бессистемный (casual) ВИ
Детальный (detailed) ВИ
1. Название (Name). Краткое,
максимально понятное, в виде команды (что сделать).
2. Цель (Goal). Краткая (до нескольких предложений) характеристика задачи, которую должен в результате решить ВИ.
3. Начальное состояние (Initial state). Формулировка условий, при которых данный ВИ может быть инициирован.
4. Основной сценарий (Main scenario). Сценарий — это последовательность шагов, описывающая процесс решения задачи, которой посвящен ВИ.
5 и т. д. — альтернативные сценарии
2. Цель (Goal). Краткая (до нескольких предложений) характеристика задачи, которую должен в результате решить ВИ.
3. Начальное состояние (Initial state). Формулировка условий, при которых данный ВИ может быть инициирован.
4. Основной сценарий (Main scenario). Сценарий — это последовательность шагов, описывающая процесс решения задачи, которой посвящен ВИ.
5 и т. д. — альтернативные сценарии
Слайд 41Варианты использования
Название: Отправить электронное письмо.
Цель: Отправить созданное письмо с проверкой корректности
его атрибутов.
Начальное состояние: Выполнен ВИ «Создать новое письмо» или ВИ «Создать ответ на письмо».
Основной сценарий:
1. Пользователь выполняет команду отправки письма.
2. Программа проверяет, правильно ли заполнено поле «Адрес».
3. Если нет, программа сообщает об ошибке и отменяет отправку. Конец.
4. Если да, то программа проверяет, заполнено ли поле «Тема».
5. Если нет, программа выдает предупреждение, но не отменяет отправку.
6. Программа помещает письмо в папку «Исходящие» и отсылает его.
7. После отправки программа перемещает письмо в папку «Отправленные».
Сценарий обработки ошибок:
Предусловие: на шаге 6 основного сценария происходит ошибка отправки письма (сбой сети и т. п.)
7. Программа сообщает об ошибке и предлагает сохранить текст письма в файл.
8. Если пользователь согласен сохранить текст, выполняется ВИ «Сохранить черновик в файл».
Начальное состояние: Выполнен ВИ «Создать новое письмо» или ВИ «Создать ответ на письмо».
Основной сценарий:
1. Пользователь выполняет команду отправки письма.
2. Программа проверяет, правильно ли заполнено поле «Адрес».
3. Если нет, программа сообщает об ошибке и отменяет отправку. Конец.
4. Если да, то программа проверяет, заполнено ли поле «Тема».
5. Если нет, программа выдает предупреждение, но не отменяет отправку.
6. Программа помещает письмо в папку «Исходящие» и отсылает его.
7. После отправки программа перемещает письмо в папку «Отправленные».
Сценарий обработки ошибок:
Предусловие: на шаге 6 основного сценария происходит ошибка отправки письма (сбой сети и т. п.)
7. Программа сообщает об ошибке и предлагает сохранить текст письма в файл.
8. Если пользователь согласен сохранить текст, выполняется ВИ «Сохранить черновик в файл».
Слайд 42Виды применения ВИ
Как средство фиксации функциональных требований на этапе анализа
как
источник информации о постановке задачи для выполнения проектирования и программной реализации системы
для тестирования системы
для написания пользовательской документации.
для тестирования системы
для написания пользовательской документации.
Слайд 43Проектирование
Хороший проектировщик обязан полагаться на опыт, на ясное логическое мышление
и на педантичную точность. Никакая магия здесь не поможет.
Никлаус Вирт
Цель — преобразовать общие внешние требования к продукту в конкретные требования к внутреннему устройству и функционированию продукта.
Никлаус Вирт
Цель — преобразовать общие внешние требования к продукту в конкретные требования к внутреннему устройству и функционированию продукта.
Слайд 44Объекты проектирования —виды проектных требований
Физическая структура (physical structure)
Логическая структура (logical structure);
Алгоритмы
(algorithms);
Структуры данных (data structures);
Пользовательский интерфейс (user interface).
Структуры данных (data structures);
Пользовательский интерфейс (user interface).
Слайд 45Архитектурное и детальное проектирование
Архитектурное проектирование = эскизное проектирование = концептуальное проектирование
= проектирование в большом (design in large)
Детальное проектирование = рабочее проектирование = техническое проектирование = проектирование в малом (design in small)
Детальное проектирование = рабочее проектирование = техническое проектирование = проектирование в малом (design in small)
Слайд 46Архитектура
Архитектура состоит из всех важных проектных решений по поводу структур программы
и взаимодействий между этими структурами, которые составляют системы
Архитектура – это фундаментальная организация системы, реализованная в ее компонентах, связях этих компонентов друг с другом и внешней средой и принципах, определяющих структуру и развитие системы
Архитектура – это разделение системы на наиболее крупные составные части; некие конструктивные решения, которые после их принятия с трудом поддаются изменению; это согласие в вопросе идентификации главных компонентов системы и способов их взаимодействия, а также выбор таких решений, которые интерпретируются как основополагающие и не подлежащие изменению в будущем.
Архитектура – это фундаментальная организация системы, реализованная в ее компонентах, связях этих компонентов друг с другом и внешней средой и принципах, определяющих структуру и развитие системы
Архитектура – это разделение системы на наиболее крупные составные части; некие конструктивные решения, которые после их принятия с трудом поддаются изменению; это согласие в вопросе идентификации главных компонентов системы и способов их взаимодействия, а также выбор таких решений, которые интерпретируются как основополагающие и не подлежащие изменению в будущем.
Слайд 47Декомпозиция проектируемой системы
Основания декомпозиции: процедурное (алгоритмическое) и объектно-ориентированное. При процедурно-ориентированной декомпозиции
выделяются процедуры, а при объектно-ориентированной — классы и объекты.
Слайд 48Декомпозиция проектируемой системы
При нисходящем проектировании (проектировании «сверху вниз», top-down design) проектирование
начинается с верхнего уровня абстракции — представления системы как «черного ящика».
При восходящем проектировании (проектировании «снизу вверх», bottom-up design) сразу выделяется множество необходимых элементов нижнего уровня реализации, затем над ними надстраивается уровень управления.
При проектировании методом расширения ядра (проектировании «от центра») выделяется базовый процесс или объект (ядро), на котором основана вся система. Проектирование ведется одновременно «вниз» (для реализации ядра на низком уровне) и «вверх» (для использования ядра на верхнем уровне).
При восходящем проектировании (проектировании «снизу вверх», bottom-up design) сразу выделяется множество необходимых элементов нижнего уровня реализации, затем над ними надстраивается уровень управления.
При проектировании методом расширения ядра (проектировании «от центра») выделяется базовый процесс или объект (ядро), на котором основана вся система. Проектирование ведется одновременно «вниз» (для реализации ядра на низком уровне) и «вверх» (для использования ядра на верхнем уровне).
Слайд 49Шаблоны проектирования
То, что мы называем хаосом, — просто шаблоны, которые мы
не распознали. То, что мы называем случайным, — шаблоны, которые мы не расшифровали.
Чак Паланик
Кристофер Александер (Christopher Alexander) в 1977 г. предложил язык описания шаблонов для планирования застройки городов и конструирования зданий.
Широкое распространение шаблоны проектирования ПО получили после выхода в 1991 г. книги «банды четырёх» Эриха Гамма (Erich Gamma), Ричарда Хелма (Richard Helm), Ральфа Джонсона (Ralph Johnson) и Джона Влиссидеса (John Vlissides) «Приёмы объектно-ориентированного проектирования. Паттерны проектирования»
Чак Паланик
Кристофер Александер (Christopher Alexander) в 1977 г. предложил язык описания шаблонов для планирования застройки городов и конструирования зданий.
Широкое распространение шаблоны проектирования ПО получили после выхода в 1991 г. книги «банды четырёх» Эриха Гамма (Erich Gamma), Ричарда Хелма (Richard Helm), Ральфа Джонсона (Ralph Johnson) и Джона Влиссидеса (John Vlissides) «Приёмы объектно-ориентированного проектирования. Паттерны проектирования»
Слайд 50Шаблоны проектирования
Шаблон (паттерн) проектирования представляет собой
формализованное описание часто встречающейся задачи
проектирования
удачное решение данной задачи
рекомендации по применению этого решения в различных ситуациях.
http://citforum.ru/SE/project/pattern/
http://c2.com/cgi/wiki?CategoryPattern
удачное решение данной задачи
рекомендации по применению этого решения в различных ситуациях.
http://citforum.ru/SE/project/pattern/
http://c2.com/cgi/wiki?CategoryPattern
Слайд 51Шаблоны проектирования
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. Шаблоны интеграции по типу обмена данными
1.3. Порождающие шаблоны проектирования
2. Архитектурные системные шаблоны
2.1. Структурные шаблоны
2.2. Шаблоны управления
2.2.1. Шаблоны централизованного управления
2.2.2. Шаблоны управления, основанные на событиях
2.2.3. Шаблоны взаимодействия с базой данных
3. Шаблоны интеграции корпоративных информационных систем
3.1. Структурные шаблоны интеграции
3.2. Шаблоны по методу интеграции
3.3. Шаблоны интеграции по типу обмена данными
Слайд 52Анти-шаблоны (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
Слайд 53Проектирование модулей
1. Модуль есть единица структуры исходного текста программы, оформляемая, как
правило, в виде отдельного файла.
2. Модуль в программных проектах является единицей компиляции, описания и администрирования.
3. Модуль имеет две логически различные части: интерфейс и реализацию.
Интерфейс модуля есть набор описаний (прототипов) функций и данных модуля, доступных «извне» модуля.
Реализация модуля есть собственно программный код функций и данных.
2. Модуль в программных проектах является единицей компиляции, описания и администрирования.
3. Модуль имеет две логически различные части: интерфейс и реализацию.
Интерфейс модуля есть набор описаний (прототипов) функций и данных модуля, доступных «извне» модуля.
Реализация модуля есть собственно программный код функций и данных.
Слайд 56Проектирование интерфейса пользователя
Для большинства пользователей интерфейс вашей системы и есть ваша
система.
Ребекка Райордан
Когнитивная психология
Физиология
Лингвистика
И др.
Чтобы сделать хороший UI, необходимо понять, как человек думает, как общается, как манипулирует предметами, как запоминает и вспоминает, как догадывается, как учится, как видит, читает и пишет.
Ребекка Райордан
Когнитивная психология
Физиология
Лингвистика
И др.
Чтобы сделать хороший UI, необходимо понять, как человек думает, как общается, как манипулирует предметами, как запоминает и вспоминает, как догадывается, как учится, как видит, читает и пишет.
Слайд 57Проектирование интерфейса пользователя
Интерфейсом (interface) двух объектов называется система правил и средств,
соответственно регламентирующих и обеспечивающих их взаимодействие.
Интерфейс пользователя (user interface) — система правил и средств, соответственно регламентирующих и обеспечивающих взаимодействие пользователя и вычислительной системы в процессе выполнения данной программы.
Интерфейс пользователя (user interface) — система правил и средств, соответственно регламентирующих и обеспечивающих взаимодействие пользователя и вычислительной системы в процессе выполнения данной программы.
Слайд 58Классификации интерфейса пользователя
По типу выводимой информации, или по типу формирования изображения,
отличают символьный интерфейс пользователя (character user interface, CUI) и графический интерфейс пользователя (graphical user interface, GUI).
По типу управления различают командный интерфейс и визуальный интерфейс.
По активной стороне выделяют классический интерфейс и интерфейс «Мастеров» (Wizards).
По типу управления различают командный интерфейс и визуальный интерфейс.
По активной стороне выделяют классический интерфейс и интерфейс «Мастеров» (Wizards).
Слайд 59Характеристики интерфейса пользователя
Дружественность (человечность)
Предсказуемость (интуитивная понятность, очевидность).
Простота
Привлекательность (эстетичность)
Целостность
Слайд 60Типичные ошибки дизайна UI
Непредсказуемость, неэстетичность, сложность, нецелостность, недружественность
Выбор неверных элементов управления
Сбивающая
с толку терминология
Перегруженность
Идиотизм в поведении
Неверные цветовые решения
Неправильные сообщения
Плохие метафоры
Перегруженность
Идиотизм в поведении
Неверные цветовые решения
Неправильные сообщения
Плохие метафоры
Слайд 61Источники ошибок дизайна UI
Отсутствие мотивации
Работает и ладно
И так сойдёт
Не мои проблемы
Да
кого это волнует
Ложная мотивация
Сделаю так «круто», чтобы все ахнули
Сделаю, как никто ещё не делал
А мне вот так интересно попробовать
Плохие примеры для подражания
Ложная мотивация
Сделаю так «круто», чтобы все ахнули
Сделаю, как никто ещё не делал
А мне вот так интересно попробовать
Плохие примеры для подражания
Слайд 67Программирование
Если отладка — процесс удаления ошибок, то программирование должно быть процессом
их внесения.
Эдсгер Дейкстра
Стандарты кодирования
Оптимизация программы
Безопасное программирование
Эдсгер Дейкстра
Стандарты кодирования
Оптимизация программы
Безопасное программирование
Слайд 68Стандарты кодирования (1)
Любой дурак способен писать код, который может понять компьютер.
Хорошие программисты пишут код, который может понять человек.
Мартин Фаулер
Снижение зависимости от конкретных разработчиков
Повышение сопровождаемости программ
Повышение культуры программирования и снижение количества ошибок
Мартин Фаулер
Снижение зависимости от конкретных разработчиков
Повышение сопровождаемости программ
Повышение культуры программирования и снижение количества ошибок
Слайд 69Стандарты кодирования (2)
Структурирование текста
Методы структурирования позволяют наглядно выявить соподчинённость конструкций и
их группирование
Разрежение текста
Методы разрежения текста позволяют облегчить чтение за счёт дополнительных пробелов (горизонтальное разрежение) и пустых строк (вертикальное разрежение)
Именование объектов
Методы именования объектов включают системы именования переменных, типов, процедур и модулей
Комментирование
Разрежение текста
Методы разрежения текста позволяют облегчить чтение за счёт дополнительных пробелов (горизонтальное разрежение) и пустых строк (вертикальное разрежение)
Именование объектов
Методы именования объектов включают системы именования переменных, типов, процедур и модулей
Комментирование
Слайд 70Стандарты кодирования (3)
Делайте функции небольшими
Функция должна делать только одно дело
Функции должны
быть функционально простыми
Избегайте глобальных переменных
Избегайте рекурсии
Избегайте глобальных переменных
Избегайте рекурсии
Слайд 71Безопасное программирование
Программирование есть соревнование между программистами, делающими больше программ с все
лучшей «защитой от дурака», и Вселенной, увеличивающей производство все более глупых идиотов. Похоже, что Вселенная пока выигрывает.
Рич Кук
Оптимистический подход
Пессимистический подход
пользователь очень часто выполняет неверные и даже недопустимые действия
входные и выходные данные могут быть некорректными
созданный программистами код заведомо содержит ошибки
внешние программы и устройства постоянно подвержены сбоям
Рич Кук
Оптимистический подход
Пессимистический подход
пользователь очень часто выполняет неверные и даже недопустимые действия
входные и выходные данные могут быть некорректными
созданный программистами код заведомо содержит ошибки
внешние программы и устройства постоянно подвержены сбоям
Слайд 72Безопасное программирование
Подход:
встраивать проверки, обнаруживающие ошибки и реагирующие на них
применять такие способы
написания кода, которые снижают вероятность внесения ошибок
Результат:
программа сама выявляет многие ошибки
сообщает о них пользователю и/или разработчику
и даже борется с ними.
Результат:
программа сама выявляет многие ошибки
сообщает о них пользователю и/или разработчику
и даже борется с ними.
Слайд 73Безопасное программирование
1. Создавать «дуракоустойчивый» (foolproof) интерфейс.
2. Проверять корректность параметров, получаемых подпрограммой, даже
если они заведомо должны быть правильными (проверка предусловий внутри подпрограммы).
3. Проверять корректность результатов, полученных в подпрограмме (проверка постусловий после вызова подпрограммы).
3. Проверять корректность результатов, полученных в подпрограмме (проверка постусловий после вызова подпрограммы).
Слайд 74Безопасное программирование
4. Проверять результаты взаимодействия с внешними устройствами и программами, в
особенности результаты файловых операций.
5. Проверять корректность указателей и индексов, чтобы исключить ошибки доступа к памяти.
6. Предотвращать ошибки арифметических операций (деление на ноль, корень из отрицательного числа, логарифм неположительного числа и т. п.), для чего вычислять соответствующие подвыражения отдельно и проверять их на корректность.
5. Проверять корректность указателей и индексов, чтобы исключить ошибки доступа к памяти.
6. Предотвращать ошибки арифметических операций (деление на ноль, корень из отрицательного числа, логарифм неположительного числа и т. п.), для чего вычислять соответствующие подвыражения отдельно и проверять их на корректность.
Слайд 75Дуракоустойчивый интерфейс
1. Делайте недоступными все элементы управления (кнопки, меню и т. д.),
которые не должны в данный момент использоваться.
2. Где возможно, заменяйте поля клавиатурного ввода на специализированные компоненты: списки выбора (Combobox, Listbox), компоненты ввода чисел со стрелками инкремента/декремента (Spin edit), диалоги выбора файлов, папок, шрифтов и т. д.
3. В полях клавиатурного ввода широко используйте маски ввода, фильтрацию недопустимых символов и другие виды проверок корректности данных.
2. Где возможно, заменяйте поля клавиатурного ввода на специализированные компоненты: списки выбора (Combobox, Listbox), компоненты ввода чисел со стрелками инкремента/декремента (Spin edit), диалоги выбора файлов, папок, шрифтов и т. д.
3. В полях клавиатурного ввода широко используйте маски ввода, фильтрацию недопустимых символов и другие виды проверок корректности данных.
Слайд 76Дуракоустойчивый интерфейс
4. При неверном вводе данных выводите пояснения, позволяющие пользователю понять
свою ошибку.
5. Для сложных задач, требующих определённой последовательности действий, создавайте Мастера (Wizards).
6. Затрудняйте случайное выполнение опасных операций (назначайте им более сложные комбинации клавиш, требуйте подтверждения и т. д.)
7. Обеспечивайте возможность отмены действий (команды Undo, Cancel).
5. Для сложных задач, требующих определённой последовательности действий, создавайте Мастера (Wizards).
6. Затрудняйте случайное выполнение опасных операций (назначайте им более сложные комбинации клавиш, требуйте подтверждения и т. д.)
7. Обеспечивайте возможность отмены действий (команды Undo, Cancel).
Слайд 77Оптимизация программы
Неважно, насколько эффективно работает программа, если она работает неправильно
Принцип Ван
Тассела
1. Оптимизация должна иметь четкую цель. Как правило, цели уменьшения размера и повышения скорости плохо совмещаются друг с другом, облегчение администрирования конфликтует с повышением безопасности и защищённости и т. д.
2. Наибольший выигрыш всегда даёт правильный выбор методов, алгоритмов и структур данных, а не локальная оптимизация кода.
3. Оптимизировать следует только «узкие места» кода. Оптимизация некритичных участков является пустой тратой времени. Для выявления «узких мест» можно использовать программы-профилировщики.
1. Оптимизация должна иметь четкую цель. Как правило, цели уменьшения размера и повышения скорости плохо совмещаются друг с другом, облегчение администрирования конфликтует с повышением безопасности и защищённости и т. д.
2. Наибольший выигрыш всегда даёт правильный выбор методов, алгоритмов и структур данных, а не локальная оптимизация кода.
3. Оптимизировать следует только «узкие места» кода. Оптимизация некритичных участков является пустой тратой времени. Для выявления «узких мест» можно использовать программы-профилировщики.
Слайд 78Тестирование
Знайте, что быть экспертом — это больше, чем понимать, как система
должна работать. Мастерство обретается исследованием того, почему она не работает.
Брайан Редман
Тестирование —
оценка/исследование правильности работы программы
или
выявление ошибок в программе?
Брайан Редман
Тестирование —
оценка/исследование правильности работы программы
или
выявление ошибок в программе?
Слайд 79Тестирование
Тестирование — это процесс анализа ПО, направленный на выявление отличий между
его реально существующими и требуемыми свойствами и на оценку свойств ПО (IEEE 829-1983 Standard for Software Test Documentation).
Ошибки:
отклонения от спецификаций, при условии, что последние существуют и являются правильными,
отклонения от требований «здравого смысла» (общесистемных требований), например, от законов математики и логики.
Ошибки:
отклонения от спецификаций, при условии, что последние существуют и являются правильными,
отклонения от требований «здравого смысла» (общесистемных требований), например, от законов математики и логики.
Слайд 80Основные понятия
Тест: эксперимент, выполняемый над программой, для которого определены критерии успешности.
Тестовые данные: это конкретные данные, подаваемые программе при эксперименте.
не только числа, строки, даты, файлы и т. д., но и действия пользователя, выполняемые при работе с пользовательским интерфейсом
Тестовая процедура (сценарий): спецификация проведения эксперимента, которая описывает порядок ввода тестовых данных и критерии успешности
Слайд 81Объекты тестирования
Исходные тексты программ
Исполняемые модули (программы, библиотеки)
Документация.
Слайд 82Три принципа тестирования
Необходимо создавать тесты, которые с высокой вероятностью находят ошибки,
а не демонстрируют правильность работы программы
Необходимо привлекать для тестирования сторонних специалистов, поскольку программист психологически неспособен выполнить исчерпывающее тестирование своего собственного кода
Тесты должны проводиться регулярно, в соответствии с планом на основании регламента.
Необходимо привлекать для тестирования сторонних специалистов, поскольку программист психологически неспособен выполнить исчерпывающее тестирование своего собственного кода
Тесты должны проводиться регулярно, в соответствии с планом на основании регламента.
Слайд 83Основные проблемы организации тестирования
Нередко отсутствует эталон, которому должны соответствовать результаты тестирования
Невозможно
создать набор тестов для исчерпывающей проверки сложной системы
Отсутствуют практически пригодные формальные критерии качества тестирования.
Отсутствуют практически пригодные формальные критерии качества тестирования.
Слайд 84Критерии качества тестирования
Не иметь ошибок — это словно жить без смысла.
Нет борьбы, нет и радости.
Брайан Портер
Критерии покрытия поведения (behavioral test coverage)
Полнота функционального тестирования
Критерии покрытия структуры (structural test coverage)
Полнота покрытия операторов
Полнота покрытия маршрутов
Полнота покрытия данных
Брайан Портер
Критерии покрытия поведения (behavioral test coverage)
Полнота функционального тестирования
Критерии покрытия структуры (structural test coverage)
Полнота покрытия операторов
Полнота покрытия маршрутов
Полнота покрытия данных
Слайд 86Основные виды тестирования
Автономное и комплексное тестирование
Тестирование белого и черного ящика
Альфа- и
бета-тестирование
Функциональное тестирование Регрессионное тестирование
Дымовое тестирование
Нагрузочное тестирование
Тестирование уязвимости
Функциональное тестирование Регрессионное тестирование
Дымовое тестирование
Нагрузочное тестирование
Тестирование уязвимости
Слайд 87Методы, используемые для тестирования
Инспекция кода
Многократная разработка
Метод эквивалентных разбиений
Метод анализа граничных значений
Слайд 88Метод эквивалентных разбиений
X: [0;100]
Поиск подстроки s в строке S
Один класс допустимых
значений [0;100] и два — недопустимых: (–∞;0) и (100;+∞)
Минимально допустимый набор классов:
{s есть в S} и {s нет в S}
Слайд 89Метод анализа граничных значений
[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.
длина(s) = длина(S);
длина(s) = длина(S)+1;
длина(s и/или S) = 0;
длина(s и/или S) = 1;
s = nil;
S = nil.
Слайд 90Средства автоматизации тестирования
Системы поддержки автоматизированного модульного тестирования
Системы учёта и отслеживания дефектов
Генераторы
тестовых данных.
Системы выявления ошибок времени выполнения
неинициализированные переменные, переполнение стека, обращение по недопустимому адресу, утечки памяти
Системы анализа покрытия
Системы тестирования пользовательского интерфейса
Системы выявления ошибок времени выполнения
неинициализированные переменные, переполнение стека, обращение по недопустимому адресу, утечки памяти
Системы анализа покрытия
Системы тестирования пользовательского интерфейса
Слайд 91Организация тестирования
Задачи
подбор команды тестирования
разработка регламента тестирования
организация разработки тестов
создание сценариев тестирования
создание тестовых
данных
контроль за исполнением регламента.
Специалисты
Тест-инженер (test engineer):
наиболее квалифицированный специалист, который владеет навыками планирования тестирования, разработки и проведения тестов, а также понимает предметную область
Тестер, тестировщик (test technician, test specialist)
менее квалифицированный специалист, который главным образом занимается выполнением тестов
контроль за исполнением регламента.
Специалисты
Тест-инженер (test engineer):
наиболее квалифицированный специалист, который владеет навыками планирования тестирования, разработки и проведения тестов, а также понимает предметную область
Тестер, тестировщик (test technician, test specialist)
менее квалифицированный специалист, который главным образом занимается выполнением тестов
Слайд 92Классификация ошибок по серьёзности
Если вы с первого раза написали программу, в
которой транслятор не обнаружил ни одной ошибки, сообщите об этом автору транслятора. Он исправит ошибки в трансляторе.
Ошибки с высокой серьёзностью
препятствуют решению важных задач
проявляются всегда или с высокой степенью вероятности.
Ошибки со средней серьёзностью
препятствуют решению маловажных задач
проявляются редко, при маловероятном стечении обстоятельств.
Ошибки с низкой серьёзностью
не препятствуют решению задач
скорее раздражают пользователей, чем по-настоящему мешают.
Ошибки с высокой серьёзностью
препятствуют решению важных задач
проявляются всегда или с высокой степенью вероятности.
Ошибки со средней серьёзностью
препятствуют решению маловажных задач
проявляются редко, при маловероятном стечении обстоятельств.
Ошибки с низкой серьёзностью
не препятствуют решению задач
скорее раздражают пользователей, чем по-настоящему мешают.
Слайд 93Классификация ошибок по видам деятельности, которые привели к их возникновению
Ошибки анализа
не предусмотрена нужная функциональность; дублирование функций; лишние функции; неверно оценены требования к техническим средствам; неверно оценены требования к производительности или переносимости.
Ошибки (архитектурного) проектирования
в рамках предложенного проекта невозможно достичь требуемой в ТЗ функциональности и критериев качества.
Ошибки программной реализации
Ошибки документации
Слайд 94Некоторые интересные факты
Есть два способа написания программ без ошибок;
но работает
только третий.
Для исправления проблем, выявленных при сопровождении продукта, программисты по статистике тратят до 60 % времени, пытаясь понять документацию и логику программы.
Фирмой IBM установлено, что в среднем одна ранее не обнаруженная ошибка появляется в каждых 100 операторах программы
Большинство ошибок содержится в сопряжениях модулей и операторах ввода-вывода
После того как проведено тестирование отдельно каждого модуля, и они объединяются в систему, в 90 % всех новых модулей и в 15 % старых необходимо вносить изменения
При этом приблизительно в 15 % новых модулей и 6 % старых следует внести более 10 изменений
Для исправления проблем, выявленных при сопровождении продукта, программисты по статистике тратят до 60 % времени, пытаясь понять документацию и логику программы.
Фирмой IBM установлено, что в среднем одна ранее не обнаруженная ошибка появляется в каждых 100 операторах программы
Большинство ошибок содержится в сопряжениях модулей и операторах ввода-вывода
После того как проведено тестирование отдельно каждого модуля, и они объединяются в систему, в 90 % всех новых модулей и в 15 % старых необходимо вносить изменения
При этом приблизительно в 15 % новых модулей и 6 % старых следует внести более 10 изменений
Слайд 95Документирование
Документация как секс:
если она качественная, это очень хорошо;
если плоха,
— это лучше, чем ничего.
Единая система программной документации (ЕСПД)
ГОСТ Р ИСО/МЭК 15910-2002 (ISO/IEC 15910-99)
Программная и эксплуатационная документация может использоваться для изготовления и сопровождения программного изделия, для его тестирования (испытания), для его эксплуатации.
Документирование должно начинаться одновременно с разработкой продукта или даже раньше
Единая система программной документации (ЕСПД)
ГОСТ Р ИСО/МЭК 15910-2002 (ISO/IEC 15910-99)
Программная и эксплуатационная документация может использоваться для изготовления и сопровождения программного изделия, для его тестирования (испытания), для его эксплуатации.
Документирование должно начинаться одновременно с разработкой продукта или даже раньше
Слайд 96Примеры эксплуатационных документов
Руководство пользователя — сведения о назначении программы, области применения,
применяемых методах, ограничениях при применении, конфигурации технических средств; сведения для обеспечения процедуры общения пользователя с вычислительной системой в процессе выполнения программы.
Руководство системного администратора — сведения для обеспечения установки, функционирования и настройки программ на условия конкретного применения.
Руководство программиста
Руководство системного администратора — сведения для обеспечения установки, функционирования и настройки программ на условия конкретного применения.
Руководство программиста
Слайд 97Терминология (1)
a) применять общие и нетехнические термины в соответствии с их
определениями, установленными в общих словарях;
b) создавать глоссарии (словники), содержащие:
1) определения всех специфических и неизвестных терминов,
2) виды и определения всех обозначений и сокращений,
3) толкования непривычного использования слов, применение имен существительных в качестве наречий,
4) библиографию специализированных словарей и стандартов;
c) специальная терминология должна быть основана на национальных или международных терминологических стандартах, общепризнанных словарях или согласованных глоссариях;
d) каждое сокращение должно быть расшифровано при первом его появлении в тексте основной части документа;
b) создавать глоссарии (словники), содержащие:
1) определения всех специфических и неизвестных терминов,
2) виды и определения всех обозначений и сокращений,
3) толкования непривычного использования слов, применение имен существительных в качестве наречий,
4) библиографию специализированных словарей и стандартов;
c) специальная терминология должна быть основана на национальных или международных терминологических стандартах, общепризнанных словарях или согласованных глоссариях;
d) каждое сокращение должно быть расшифровано при первом его появлении в тексте основной части документа;
Слайд 98Терминология (2)
e) каждый термин должен одинаково трактоваться в документе, диалоговой информации
и системной библиотеке;
f) составные выражения (например, «ввод данных [data input]») должны иметь одно смысловое значение во всей документации;
g) составные выражения не должны содержать более трех слов;
h) одно и то же слово не должно использоваться для различных частей речи;
i) все специфические и специальные термины должны использоваться в соответствующем контексте;
j) термины, вводимые вне соответствующего контекста, например наименования клавиш или команды, должны быть определены в глоссарии
f) составные выражения (например, «ввод данных [data input]») должны иметь одно смысловое значение во всей документации;
g) составные выражения не должны содержать более трех слов;
h) одно и то же слово не должно использоваться для различных частей речи;
i) все специфические и специальные термины должны использоваться в соответствующем контексте;
j) термины, вводимые вне соответствующего контекста, например наименования клавиш или команды, должны быть определены в глоссарии
Слайд 99Физические факторы
a) сокращения нецелесообразно использовать только для экономии места;
b) предусмотреть необходимые
места для простановки соответствующих значений, например цены;
c) следует использовать стандартные графические инструментальные средства (пакеты) и избегать применения вклеек;
d) избегать внесения поясняющего текста в рисунки;
e) следует использовать графические символы, имеющие общепринятое смысловое значение;
f) по возможности вместо словесного пояснения использовать графические изображения.
c) следует использовать стандартные графические инструментальные средства (пакеты) и избегать применения вклеек;
d) избегать внесения поясняющего текста в рисунки;
e) следует использовать графические символы, имеющие общепринятое смысловое значение;
f) по возможности вместо словесного пояснения использовать графические изображения.
Слайд 100Диалоговая информация
a) при наличии обратной связи с разработчиками программных средств следует
обеспечить выделение диалоговой информации (текстов и сообщений) из логики программы;
b) каждый блок текста или сообщение должны иметь индивидуальное идентификационное обозначение с указанием соответствующей классификационной группы данного текста или сообщения;
c) конкретное программное средство не должно ориентироваться на длину, формат или расположение экранных полей ввода-вывода (input and output fields);
d) для каждого понятия следует использовать отдельное сообщение. Сообщения не должны быть надуманными;
e) переменные в сообщении должны содержать только непереводимую информацию, например ключевые слова и коды возврата;
f) из предложений не следует исключать предлоги в целях экономии места.
b) каждый блок текста или сообщение должны иметь индивидуальное идентификационное обозначение с указанием соответствующей классификационной группы данного текста или сообщения;
c) конкретное программное средство не должно ориентироваться на длину, формат или расположение экранных полей ввода-вывода (input and output fields);
d) для каждого понятия следует использовать отдельное сообщение. Сообщения не должны быть надуманными;
e) переменные в сообщении должны содержать только непереводимую информацию, например ключевые слова и коды возврата;
f) из предложений не следует исключать предлоги в целях экономии места.
Слайд 101Культурные факторы (1)
a) иллюстративные материалы (например, лица, животные и звуки речи)
должны быть независимыми от национальных культурных особенностей;
b) следует избегать использования примеров, связанных со специфическими национальными традициями или особенностями (например, праздниками, банковским делом, зарплатой, спортом и т.д.);
c) в тексте и иллюстрациях следует избегать использования идиоматических выражений, присущих национальному языку документатора;
d) следует избегать использования юмористических выражений, особенно каламбуров.
e) следует осторожно использовать иронические выражения;
b) следует избегать использования примеров, связанных со специфическими национальными традициями или особенностями (например, праздниками, банковским делом, зарплатой, спортом и т.д.);
c) в тексте и иллюстрациях следует избегать использования идиоматических выражений, присущих национальному языку документатора;
d) следует избегать использования юмористических выражений, особенно каламбуров.
e) следует осторожно использовать иронические выражения;
Слайд 102Культурные факторы (2)
f) необходимо избегать использования сленговых, жаргонных и простонародных выражений;
g)
не должны использоваться упоминания первых лиц государства;
h) не следует выражать даты только в числовом виде. Месяц всегда должен быть написан полностью (например, 28 июля 1991);
i) обычно следует использовать двумерные представления, если международные соглашения не требуют иного (например, для автошин, водопроводов, гвоздей и фотопленки);
j) когда метрические величины располагаются вместе с величинами в других системах измерения, из контекста должно быть понятно, какая из величин относится к соответствующей системе измерений.
h) не следует выражать даты только в числовом виде. Месяц всегда должен быть написан полностью (например, 28 июля 1991);
i) обычно следует использовать двумерные представления, если международные соглашения не требуют иного (например, для автошин, водопроводов, гвоздей и фотопленки);
j) когда метрические величины располагаются вместе с величинами в других системах измерения, из контекста должно быть понятно, какая из величин относится к соответствующей системе измерений.
Слайд 103Выпуск
Основные этапы готовности продукта:
Реализация базовых функций
множество возможностей ещё отсутствуют, однако все
базовые уже реализованы
2. Альфа-версия
завершенный, но ещё полный ошибок продукт
имеются практически все её функции, однако некоторые могут работать крайне нестабильно
интерфейс и документация находятся в стадии доработки
3. Бета-версия
практически законченный продукт, в котором разработчики выполнили своими силами всё возможное тестирование
4. Релиз
приёмо-сдаточные испытания
2. Альфа-версия
завершенный, но ещё полный ошибок продукт
имеются практически все её функции, однако некоторые могут работать крайне нестабильно
интерфейс и документация находятся в стадии доработки
3. Бета-версия
практически законченный продукт, в котором разработчики выполнили своими силами всё возможное тестирование
4. Релиз
приёмо-сдаточные испытания
Слайд 104Приёмо-сдаточные испытания
Общее планирование испытаний :
Разработка общей стратегии испытаний системы
Календарный график проведения
испытаний
планирование ресурсов
планирование видов испытаний
планирование состава комиссии для каждого испытания
Детальное планирование испытаний
Выявить условия, демонстрирующие функционирование системы с точки зрения пользователей
Подготовить демонстрационные тесты
подготовить демонстрационные данные
подготовить демонстрационные сценарии
Описать программу и методику испытаний
планирование ресурсов
планирование видов испытаний
планирование состава комиссии для каждого испытания
Детальное планирование испытаний
Выявить условия, демонстрирующие функционирование системы с точки зрения пользователей
Подготовить демонстрационные тесты
подготовить демонстрационные данные
подготовить демонстрационные сценарии
Описать программу и методику испытаний
Слайд 107Оценка качества ПО
Измеряй то, что измеримо,
и делай измеримым то, что
нельзя измерить.
Галилео Галилей
Квалиметрия: дисциплина, изучающая количественную оценку качества
теоретическая: математические модели
прикладная: конкретные видов объектов
географическая
педагогическая
…
Галилео Галилей
Квалиметрия: дисциплина, изучающая количественную оценку качества
теоретическая: математические модели
прикладная: конкретные видов объектов
географическая
педагогическая
…
Слайд 108Понятие качества
Качество программы (quality) — весь объём признаков и характеристик программы,
который относится к её способности удовлетворять установленным или предполагаемым потребностям.
Уровень качества функционирования (level of performance) — степень, в которой удовлетворяются потребности, представленные конкретным набором значений для характеристик качества.
Уровень качества функционирования (level of performance) — степень, в которой удовлетворяются потребности, представленные конкретным набором значений для характеристик качества.
Слайд 109Свойства программного средства
Функциональные свойства
Отражают возможности и специфику применения программы и
обусловливают степень её соответствия своему целевому назначению. Они характеризуют программу с точки зрения того, как в действительности она выполняется.
Конструктивные свойства
Характеризуют программу с точки зрения того, как в действительности она сконструирована, устроена. Более или менее не зависят от её функциональных возможностей и назначения.
Конструктивные свойства
Характеризуют программу с точки зрения того, как в действительности она сконструирована, устроена. Более или менее не зависят от её функциональных возможностей и назначения.
Слайд 110Методы оценки свойств ПО
ГОСТ 28195-89 «Оценка качества программных средств»
по способам получения
информации
измерительный,
регистрационный,
органолептический,
расчётный;
по источникам получения информации
традиционный,
экспертный,
Социологический.
измерительный,
регистрационный,
органолептический,
расчётный;
по источникам получения информации
традиционный,
экспертный,
Социологический.
Слайд 111Номенклатура показателей качества
ГОСТ Р ИСО/МЭК 9126-93. «Оценка программной продукции. Характеристики качества
и руководства по их применению»
Функциональные возможности (Functionality)
Надёжность (Reliability)
Практичность (Usability)
Эффективность (Efficiencies)
Сопровождаемость (Maintainability)
Мобильность (Portability)
Функциональные возможности (Functionality)
Надёжность (Reliability)
Практичность (Usability)
Эффективность (Efficiencies)
Сопровождаемость (Maintainability)
Мобильность (Portability)
Слайд 112Описание методов программной инженерии
«Essence: Kernel and Language for Software Engineering Methods»
(«Основы: ядро и язык методов программной инженерии») — стандарт OMG 2013 г., созданный SEMAT.
OMG (Object Management Group): консорциум по стандартам в компьютерной индустрии, основан в 1989 г.
SEMAT (Software Engineering Method and Theory): консорциум по унификации теории программной инженерии, основан в 2009 г.
OMG (Object Management Group): консорциум по стандартам в компьютерной индустрии, основан в 1989 г.
SEMAT (Software Engineering Method and Theory): консорциум по унификации теории программной инженерии, основан в 2009 г.
Слайд 113Ядро (Kernel)
Ядро программной инженерии (Software Engineering Kernel) — минимальный набор определений,
который выражает суть программной инженерии способом, независимым от конкретных практик.
Альфы (Alphas) — ключевые понятия (essential things to work with).
Типовые деятельности (Activity Spaces) — ключевые типы деятельности (essential things to do).
Компетенции (Competencies) — ключевые способности (the abilities needed).
Альфы (Alphas) — ключевые понятия (essential things to work with).
Типовые деятельности (Activity Spaces) — ключевые типы деятельности (essential things to do).
Компетенции (Competencies) — ключевые способности (the abilities needed).
Слайд 114Ядро: Альфа
Ключевой элемент, с помощью оценки состояния которого которого можно оценить
прогресс и успешность проекта.
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.
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.
Слайд 115Ядро: Типовая деятельность
Заготовка (placeholder) для типовой деятельности в проекте.
Называет, что должно
делаться, но не предписывает как именно.
A placeholder for something to be done in the software engineering endeavor. A placeholder may consist of zero to many activities.
A placeholder for something to be done in the software engineering endeavor. A placeholder may consist of zero to many activities.
Слайд 116Ядро: Компетенция
Характеристика представителя стейкхолдера или члена команды с точки зрения способности
к определённой работе.
A characteristic of a stakeholder or team member that reflects the ability to do work.
A characteristic of a stakeholder or team member that reflects the ability to do work.
Слайд 119Альфы (область клиента)
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.
2. Stakeholders: The people, groups, or organizations who affect or are affected by a software system.
Слайд 120Альфы (область решения)
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.
4. Software System: A system made up of software, hardware, and data that provides its primary value by the execution of the software.
Слайд 121Альфы (область предпринятия)
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.
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.
