Программирование
<<  Библиотеки и издательства в новой медийной среде UniMod: метод и средство разработки реактивных объектно-ориентированных программ с явным выделением состояний  >>
Кризис ПО
Кризис ПО
Кризис ПО
Кризис ПО
Кризис ПО
Кризис ПО
Кризис ПО
Кризис ПО
Кризис ПО
Кризис ПО
Кризис ПО
Кризис ПО
Водопадная (waterfall)
Водопадная (waterfall)
Эволюционная (IID)
Эволюционная (IID)
Декомпозиция проектируемой системы
Декомпозиция проектируемой системы
Качество проектирования модулей
Качество проектирования модулей
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Примеры ошибок дизайна UI
Полнота покрытия маршрутов
Полнота покрытия маршрутов
Альфы
Альфы
Альфы
Альфы
Стейкхолдеры: состояния
Стейкхолдеры: состояния
Возможности: состояния
Возможности: состояния
Требования: состояния
Требования: состояния
Система: состояния
Система: состояния
Команда: состояния
Команда: состояния
Работа: состояния
Работа: состояния
Технология работы: состояния
Технология работы: состояния
Типовые деятельности
Типовые деятельности
Компетенции
Компетенции
Технологии программирования Software engineering
Технологии программирования Software engineering
Картинки из презентации «Технологии программирования Software engineering» к уроку информатики на тему «Программирование»

Автор: Евгений Мирошниченко. Чтобы познакомиться с картинкой полного размера, нажмите на её эскиз. Чтобы можно было использовать все картинки для урока информатики, скачайте бесплатно презентацию «Технологии программирования Software engineering.pptx» со всеми картинками в zip-архиве размером 3936 КБ.

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

содержание презентации «Технологии программирования Software engineering.pptx»
Сл Текст Сл Текст
1Технологии программирования Software 70глобальных переменных Избегайте рекурсии.
engineering. Евгений Александрович 71Безопасное программирование.
Мирошниченко доцент кафедры вычислительной Программирование есть соревнование между
техники, к. т. н. В США водопроводчик про­грам­мистами, делающими больше
учится около 8 лет. И это чтобы починить программ с все лучшей «защитой от дурака»,
мой чёртов унитаз. Ну, и сколько же вы и Вселенной, увеличивающей производство
должны учиться, чтобы вам позволили все более глупых идиотов. Похоже, что
создавать программы для самолетов с Вселенная пока выигрывает. Рич Кук
сотнями людей на борту? Джеймс Коплиен. Оптимистический подход Пессимистический
2Литература, вопросы к экзамену. подход пользователь очень часто выполняет
http://metod.ce.cctpu.edu.ru/edu/df/se/ неверные и даже недопустимые действия
Брауде Э. Технология разработки входные и выходные данные могут быть
программного обеспечения. — СПб.: «Питер», некорректными созданный программистами код
2004. — 655 с.: ил. Брукс Ф. Мифический заведомо содержит ошибки внешние программы
человеко-месяц или как создаются и устройства постоянно подвержены сбоям.
программные си-стемы: Пер. с англ. — СПб.: 72Безопасное программирование. Подход:
Символ-Плюс, 1999. — 304 с.: ил. Орлов встраивать проверки, обнаруживающие ошибки
С.А. Технологии разработки программного и реагирующие на них применять такие
обеспечения, 2-е изд. — СПб.: способы написания кода, которые снижают
"Питер", 2003. — 473 с.: ил. вероятность внесения ошибок Результат:
Якобсон А., Буч Г., Рамбо Дж. программа сама выявляет многие ошибки
Унифицированный процесс разработки сообщает о них пользователю и/или
программного обеспечения. — СПб.: Питер, разработчику и даже борется с ними.
2002. — 496 с.: ил. Гамма Э., Хелм Р., 73Безопасное программирование. 1.
Джонсон Р., Влиссидес Дж. Приемы Создавать «дуракоустойчивый» (foolproof)
объектно-ориентированного проектирования. интерфейс. 2. Проверять корректность
Паттерны проектирования. — СПб.: Питер, параметров, получаемых подпрограммой, даже
2001. — 368 с.: ил. Дастин Э., Рэшка Дж., если они заведомо должны быть правильными
Пол Дж. Автоматизированное тестирование (проверка предусловий внутри
программного обеспечения. Внедрение, подпрограммы). 3. Проверять корректность
управление и эксплуатация: Пер. с англ. — результатов, полученных в подпрограмме
М: Лори, 2003. — 567 с.: ил. Йордан Э. (проверка постусловий после вызова
Путь камикадзе. Как разработчику подпрограммы).
программного обеспечения выжить в 74Безопасное программирование. 4.
безнадежном проекте. — М.: Лори, 2003. — Проверять результаты взаимодействия с
255 с. внешними устройствами и программами, в
3Виды обеспечения ВС. математическое: особенности результаты файловых операций.
методы, алгоритмы; лингвистическое: языки, 5. Проверять корректность указателей и
способы взаимодействия; информационное: индексов, чтобы исключить ошибки доступа к
данные; программное: программы; памяти. 6. Предотвращать ошибки
техническое: аппаратные средства; арифметических операций (деление на ноль,
методическое: документы, методики; корень из отрицательного числа, логарифм
организационное: правила, регламенты, неположительного числа и т. п.), для чего
процедуры. Прошедшая испытания программа вычислять соответствующие подвыражения
или программная система, полностью готовая отдельно и проверять их на корректность.
для продажи (поставки) и снабженная всей 75Дуракоустойчивый интерфейс. 1. Делайте
необходимой документацией, называется недоступными все элементы управления
программным продуктом, изделием или (кнопки, меню и т. д.), которые не должны
средством (software product, production в данный момент использоваться. 2. Где
program). возможно, заменяйте поля клавиатурного
4Software engineering. Применение ввода на специализированные компоненты:
систематического, упорядоченного, списки выбора (Combobox, Listbox),
измеримого подхода к разработке, компоненты ввода чисел со стрелками
использованию и сопровождению ПО, то есть инкремента/декремента (Spin edit), диалоги
использование инженерного искусства в ПО. выбора файлов, папок, шрифтов и т. д. 3. В
Создание подходов п. (1). полях клавиатурного ввода широко
5Кризис ПО. Чего хотел пользователь. используйте маски ввода, фильтрацию
Как было предложено организатором недопустимых символов и другие виды
разработки. Как было описано в техническом проверок корректности данных.
задании. Как было спроектировано ведущим 76Дуракоустойчивый интерфейс. 4. При
системным специалистом. Как было неверном вводе данных выводите пояснения,
реализовано программистами. Как было позволяющие пользователю понять свою
внедрено. ошибку. 5. Для сложных задач, требующих
6в 1995 г. ожидалось, что только 9 % определённой последователь­ности действий,
проектов, выполняемых крупными компаниями, создавайте Мастера (Wizards). 6.
будут завершены в срок и без превышения Затрудняйте случайное выполнение опасных
запланированного бюджета; 52 % проектов операций (назначайте им более сложные
должны были стоить в среднем 189 % от их комбинации клавиш, требуйте подтверждения
первоначально оцененной стоимости; в то же и т. д.) 7. Обеспечивайте возможность
время 31 % всех проектов вообще ожидало отмены действий (команды Undo, Cancel).
приостановление или полное прекращение, 77Оптимизация программы. Неважно,
причем затраты на них — ничем не насколько эффективно работает программа,
компенсируемые убытки — оценивались ни если она работает неправильно Принцип Ван
много ни мало в 81 млрд долл. Через Тассела 1. Оптимизация должна иметь четкую
десятилетие, в 2004 г. 18 % проектов цель. Как правило, цели уменьшения размера
провалились, 53 % (более половины!) — не и повышения скорости плохо совмещаются
уложились в заданный бюджет или сроки, друг с другом, облегчение
только 29 % были признаны успешными. администрирования конфликтует с повышением
7Сложность разработки ПО Управление безопасности и защищённости и т. д. 2.
сложностью — суть программирования. Брайан Наибольший выигрыш всегда даёт правильный
Керниган. Сложность предметной области выбор методов, алгоритмов и структур
Внутренняя сложность программ Отсутствие данных, а не локальная оптимизация кода.
хороших способов представления больших 3. Оптимизировать следует только «узкие
систем Трудности управления процессом места» кода. Оптимизация некритичных
разработки Изменение требований к участков является пустой тратой времени.
программе в процессе её разработки. Для выявления «узких мест» можно
8Жизненный цикл программного продукта. использовать программы-профилировщики.
ISO/IEC 12207:2008 «System and software 78Тестирование. Знайте, что быть
engineering — Software life cycle экспертом — это больше, чем понимать, как
processes» ГОСТ Р ИСО/МЭК 12207—2010 система должна работать. Мастерство
Информационная технология. Системная и обретается исследованием того, почему она
программная инженерия. Процессы жизненного не работает. Брайан Редман Тестирование —
цикла программных средств. оценка/исследование правильности работы
9Жизненный цикл. Жизненный цикл (ЖЦ) программы или выявление ошибок в
программного средства есть совокупность программе?
взаимосвязанных процессов создания и 79Тестирование. Тестирование — это
последовательного изменения его состояния процесс анализа ПО, направленный на
— от формирования исходных требований до выявление отличий между его реально
окончания эксплуатации. Процесс ЖЦ — существующими и требуемыми свойствами и на
конкретный вид деятельности, оценку свойств ПО (IEEE 829-1983 Standard
систематически выполняющийся для решения for Software Test Documentation). Ошибки:
определённых задач ЖЦ. отклонения от спецификаций, при условии,
10Группы процессов ЖЦ. A) процессы что последние существуют и являются
соглашения — 2 b) процессы правильными, отклонения от требований
организационного обеспечения проекта — 5 «здравого смысла» (общесистемных
c) процессы проекта — 7; d) технические требований), например, от законов
процессы — 11 e) процессы реализации математики и логики.
программных средств — 7 f) процессы 80Основные понятия. Тест: эксперимент,
поддержки программных средств — 8 g) выполняемый над программой, для которого
процессы повторного применения программных определены критерии успешности. Тестовые
средств — 3. данные: это конкретные данные, подаваемые
11Процессы соглашения. Поставка программе при эксперименте. не только
Приобретение. числа, строки, даты, файлы и т. д., но и
12Процессы организационного обеспечения действия пользователя, выполняемые при
проекта. A) процесс менеджмента модели работе с пользовательским интерфейсом
жизненного цикла; b) процесс менеджмента Тестовая процедура (сценарий):
инфраструктуры; c) процесс менеджмента спецификация проведения эксперимента,
портфеля проектов; d) процесс менеджмента которая описывает порядок ввода тестовых
людских ресурсов; e) процесс менеджмента данных и критерии успешности.
качества. 81Объекты тестирования. Исходные тексты
13Процессы проекта. Процессы менеджмента программ Исполняемые модули (программы,
проекта процесс планирования проекта; библиотеки) Документация.
процесс управления и оценки проекта. 82Три принципа тестирования. Необходимо
Процессы поддержки проекта процесс создавать тесты, которые с высокой
менеджмента решений; процесс менеджмента вероятностью находят ошибки, а не
рисков; процесс менеджмента конфигурации; демонстрируют правильность работы
процесс менеджмента информации; процесс программы Необходимо привлекать для
измерений. тестирования сторонних специалистов,
14Технические процессы. A) определение поскольку программист психологически
требований правообладателей b) анализ неспособен выполнить исчерпывающее
системных требований c) проектирование тестирование своего собственного кода
архитектуры системы d) процесс реализации Тесты должны проводиться регулярно, в
e) процесс комплексирования системы f) соответствии с планом на основании
процесс квалификационного тестирования регламента.
системы g) процесс инсталляции программных 83Основные проблемы организации
средств h) процесс поддержки приемки тестирования. Нередко отсутствует эталон,
программных средств i) процесс которому должны соответствовать результаты
функционирования программных средств j) тестирования Невозможно создать набор
процесс сопровождения программных средств тестов для исчерпывающей проверки сложной
k) процесс изъятия из обращения системы Отсутствуют практически пригодные
программных средств. формальные критерии качества тестирования.
15Процессы реализации программных 84Критерии качества тестирования. Не
средств. А) процесс анализа требований к иметь ошибок — это словно жить без смысла.
программным средствам; b) процесс Нет борьбы, нет и радости. Брайан Портер
проектирования архитектуры программных Критерии покрытия поведения (behavioral
средств; c) процесс детального test coverage) Полнота функционального
проектирования программных средств; d) тестирования Критерии покрытия структуры
процесс конструирования программных (structural test coverage) Полнота
средств; e) процесс комплексирования покрытия операторов Полнота покрытия
программных средств; f) процесс маршрутов Полнота покрытия данных.
квалификационного тестирования программных 85Полнота покрытия маршрутов. Сто
средств. триллионов (1014) маршрутов выполнения.
16Процессы поддержки программных 86Основные виды тестирования. Автономное
средств. A) процесс менеджмента и комплексное тестирование Тестирование
документации программных средств; b) белого и черного ящика Альфа- и
процесс менеджмента конфигурации бета-тестирование Функциональное
программных средств; c) процесс тестирование Регрессионное тестирование
обеспечения гарантии качества программных Дымовое тестирование Нагрузочное
средств; d) процесс верификации тестирование Тестирование уязвимости.
программных средств; e) процесс валидации 87Методы, используемые для тестирования.
программных средств; f) процесс ревизии Инспекция кода Многократная разработка
программных средств; g) процесс аудита Метод эквивалентных разбиений Метод
программных средств; h) процесс решения анализа граничных значений.
проблем в программных средствах. 88Метод эквивалентных разбиений. X:
17Процессы повторного применения [0;100] Поиск подстроки s в строке S. Один
программных средств. A) процесс класс допустимых значений [0;100] и два —
проектирования доменов; b) процесс недопустимых: (–?;0) и (100;+?).
менеджмента повторного применения активов; Минимально допустимый набор классов: {s
c) процесс менеджмента повторного есть в S} и {s нет в S}.
применения программ. 89Метод анализа граничных значений. S в
18Модели разработки. Водопадная S: длина(s) = длина(s)–1; длина(s) =
(каскадная, последовательная) Эволюционная длина(s); длина(s) = длина(s)+1; длина(s
(итеративная, инкрементальная). и/или S) = 0; длина(s и/или S) = 1; s =
19Водопадная (waterfall). nil; S = nil. [0;100]: {–0,00001; 0;
20Эволюционная (IID). 0,00001; 99,99999; 100; 100,00001}.
21Методологии разработки. 90Средства автоматизации тестирования.
Последовательность работ и их содержание; Системы поддержки автоматизированного
артефакты, которые необходимо создавать в модульного тестирования Системы учёта и
процессе работы: документы, диаграммы, отслеживания дефектов Генераторы тестовых
исходные тексты и т. д.; организацию данных. Системы выявления ошибок времени
команды и ролевую ответственность выполнения неинициализированные
специалистов; лучшие практики (best переменные, переполнение стека, обращение
practices), позволяющие максимально по недопустимому адресу, утечки памяти
эффективно воспользоваться методологией и Системы анализа покрытия Системы
её моделью. тестирования пользовательского интерфейса.
22Методологии разработки. Единая система 91Организация тестирования. Задачи
программной документации (ЕСПД) Microsoft подбор команды тестирования разработка
Solutions Framework (MSF) Rational Unified регламента тестирования организация
Process (RUP) Agile-методологии разработки тестов создание сценариев
Экстремальное программирование (eXtreme тестирования создание тестовых данных
Programming, XP) Adaptive Software контроль за исполнением регламента.
Development (ASD), Lean Development, Специалисты Тест-инженер (test engineer):
SCRUM, Feature Driven Development (FDD), наиболее квалифицированный специалист,
Dynamic Systems Development Method (DSDM), который владеет навыками планирования
Crystal Clear. тестирования, разработки и проведения
23Выбор и адаптация методологии. Масштаб тестов, а также понимает предметную
проекта Надёжность программы область Тестер, тестировщик (test
Распределённость команды Новизна проекта technician, test specialist) менее
Требования заказчика Долговечность квалифицированный специалист, который
проекта. главным образом занимается выполнением
24Управление проектом. Управлять тестов.
программистами — это всё равно, что 92Классификация ошибок по серьёзности.
пытаться пасти котов. Грег Сетл Проект = Если вы с первого раза написали программу,
Design = модель будущей системы Проект = в которой транслятор не обнаружил ни одной
Project = комплекс действий, направленных ошибки, сообщите об этом автору
на создание продукта или услуги. транслятора. Он исправит ошибки в
25Основные задачи. Планирование трансляторе. Ошибки с высокой серьёзностью
(planning) Контроль исполнения (tracking препятствуют решению важных задач
and oversight). проявляются всегда или с высокой степенью
26Планирование. Структура декомпозиции вероятности. Ошибки со средней
работ (work breakdown structure, WBS), или серьёзностью препятствуют решению
иерархическая структура работ Исполнители маловажных задач проявляются редко, при
Время Планирование = отображение списка маловероятном стечении обстоятельств.
работ на список исполнителей во времени. Ошибки с низкой серьёзностью не
27Планирование. Железный треугольник препятствуют решению задач скорее
(треугольник возможностей): Если жёстко раздражают пользователей, чем
задан (неизменяем) какой-то один из этих по-настоящему мешают.
параметров, то можно варьировать одним из 93Классификация ошибок по видам
двух оставшихся. Последний неизбежно будет деятельности, которые привели к их
функцией двух первых. Время. Качество возникновению. Ошибки анализа не
(возможности, требования). Деньги предусмотрена нужная функциональ­ность;
(ресурсы, люди). дублирование функций; лишние функции;
28Управление конфигурацией. Как неверно оценены требования к техническим
организовать согласованную коллективную средствам; неверно оценены требования к
работу множества людей с одними и теми же производительности или переносимости.
файлами и документами; как хранить версии Ошибки (архитектурного) проектирования в
всех файлов (текстов программ, электронных рамках предложенного проекта невозможно
документов), чтобы предотвратить потерю достичь требуемой в ТЗ функциональности и
или порчу информации и обеспечить откат к критериев качества. Ошибки программной
нужной версии; как в точности определить, реализации Ошибки документации.
кто и какие изменения внёс. 94Некоторые интересные факты. Есть два
29Управление конфигурацией. Конфигурация способа написания программ без ошибок; но
в данном контексте понимается как работает только третий. Для исправления
совокупность всей информации о проекте. проблем, выявленных при сопровождении
Конфигурация физически распределена по продукта, программисты по статистике
файлам и документам проекта (состав и тратят до 60 % времени, пытаясь понять
содержание всех материалов проекта и документацию и логику программы. Фирмой
образует текущую конфигурацию). Как IBM установлено, что в среднем одна ранее
правило, это исходные тексты и бинарные не обнаруженная ошибка появляется в каждых
файлы разрабатываемой программы и вся 100 операторах программы Большинство
сопроводительная и организационная ошибок содержится в сопряжениях модулей и
документация. операторах ввода-вывода После того как
30Задачи. Определить что надо хранить проведено тестирование отдельно каждого
(выполнить конфигурационную модуля, и они объединяются в систему, в 90
идентификацию); организовать хранение всей % всех новых модулей и в 15 % старых
истории изменений; организовать необходимо вносить изменения При этом
согласованность внесения изменений приблизительно в 15 % новых модулей и 6 %
(контроль конфигурации); организовать старых следует внести более 10 изменений.
хранение моментальных снимков (версий) 95Документирование. Документация как
конфигурации, то есть согласованных секс: если она качественная, это очень
состояний проекта в некоторые важные хорошо; если плоха, — это лучше, чем
моменты времени. ничего. Единая система программной
31Внедрение и управление. Внедрение документации (ЕСПД) ГОСТ Р ИСО/МЭК
управления конфигурацией: выбор и 15910-2002 (ISO/IEC 15910-99) Программная
внедрение системы управления версиями и эксплуатационная документация может
(version control system); разработка использоваться для изготовления и
организационного обеспечения (регламента). сопровождения программного изделия, для
Дальнейшее управление: управление составом его тестирования (испытания), для его
конфигурации; управление правами доступа к эксплуатации. Документирование должно
системе управления версиями; разрешение начинаться одновременно с разработкой
проблем; резервное копирование (backup). продукта или даже раньше.
32Оценка качества процесса разработки. 96Примеры эксплуатационных документов.
Насколько «правильно» данная организация Руководство пользователя — сведения о
производит продукцию? ISO серии 9000 CMM назначении программы, области применения,
(Capability Maturity Model) — модель применяемых методах, ограничениях при
зрелости возможностей ISO/IEC 15504: применении, конфигурации технических
Information Technology — Software Process средств; сведения для обеспечения
Assessment = SPICE (Software Process процедуры общения пользователя с
Improvement and Capability dEtermination). вычислительной системой в процессе
33CMM (Capability Maturity Model). выполнения программы. Руководство
34CMM. 1. Начальный уровень (Initial системного администратора — сведения для
level) В организации царит анархия при обеспечения установки, функционирования и
разработке, нет четких процессов настройки программ на условия конкретного
управления и четких инженерных процессов. применения. Руководство программиста.
Могут существовать стандарты и инструкции, 97Терминология (1). A) применять общие и
но им никто не следует. Неравномерность нетехнические термины в соответствии с их
процесса разработки — наличие затиший и определениями, установленными в общих
авралов в работе 2. Повторяемый уровень словарях; b) создавать глоссарии
(Repeatable level) Внедрено управление (словники), содержащие: 1) определения
проектами, управление конфигурацией. всех специфических и неизвестных терминов,
Полная зависимость от конкретных личностей 2) виды и определения всех обозначений и
сохраняется, а организация имеет сильную сокращений, 3) толкования непривычного
тенденцию «сползания» к начальному уровню. использования слов, применение имен
3. Определённый уровень (Defined level) существительных в качестве наречий, 4)
Процессы управления интегрированы с библиографию специализированных словарей и
инженерными процессами (методологий стандартов; c) специальная терминология
разработки) в единый стандартный должна быть основана на национальных или
документированный программный процесс. Нет международных терминологических
деградации процесса в стрессовых ситуациях стандартах, общепризнанных словарях или
4. Управляемый уровень (Managed level) согласованных глоссариях; d) каждое
Устанавливаются количественные показатели сокращение должно быть расшифровано при
качества, которые собираются с помощью первом его появлении в тексте основной
специального измерительного инструментария части документа;
и оперативно анализируются менеджерами. 98Терминология (2). E) каждый термин
Достигается полное управление проектами и должен одинаково трактоваться в документе,
предсказуемость программного процесса и диалоговой информации и системной
качества программ. 5. Оптимизирующий библиотеке; f) составные выражения
уровень (Optimizing level) Организация (например, «ввод данных [data input]»)
постоянно и целенаправленно занимается должны иметь одно смысловое значение во
улучшением существующих процессов, и всей документации; g) составные выражения
делает это полностью контролируемым не должны содержать более трех слов; h)
образом. Организация нацелена на одно и то же слово не должно
предупреждение дефектов (defect использоваться для различных частей речи;
prevention). i) все специфические и специальные термины
35CMMI. В 2000 г. SEI предложил сменить должны использоваться в соответствующем
CMM новой, улучшенной моделью — CMMI контексте; j) термины, вводимые вне
(Capability Maturity Model for соответствующего контекста, например
Integration). CMMI фактически является наименования клавиш или команды, должны
обобщением CMM, поскольку рассматривает не быть определены в глоссарии.
только процессы разработки, как CMM, но и 99Физические факторы. A) сокращения
другие процессы ЖЦ (приобретение, нецелесообразно использовать только для
сопровождение и т. д.) Часто используется экономии места; b) предусмотреть
сокращение CMM/CMMI. необходимые места для простановки
36Анализ требований. Анализ требований соответствующих значений, например цены;
представляет собой исследование предметной c) следует использовать стандартные
области, выявление роли и места будущей графические инструментальные средства
программной системы, её основных функций и (пакеты) и избегать применения вклеек; d)
характеристик. Формальным результатом избегать внесения поясняющего текста в
анализа является спецификация требований рисунки; e) следует использовать
(requirements/product/preliminary графические символы, имеющие общепринятое
specification) в том или ином виде. смысловое значение; f) по возможности
37Основные работы при анализе. Исходная вместо словесного пояснения использовать
постановка задачи Сбор и исследование графические изображения.
информации Данные о предметной области в 100Диалоговая информация. a) при наличии
целом. Данные о существующих аналогах. обратной связи с разработчиками
Данные о специфике предприятия-заказчика: программных средств следует обеспечить
специфика бизнес-процессов организации; выделение диалоговой информации (текстов и
данные об унаследованном ПО (legacy сообщений) из логики программы; b) каждый
software); используемое аппаратное блок текста или сообщение должны иметь
обеспечение; политика безопасности индивидуальное идентификационное
организации; уровень квалификации обозначение с указанием соответствующей
персонала. Выбор приоритетных критериев классификационной группы данного текста
качества Определение входных, хранимых и или сообщения; c) конкретное программное
выходных данных Формализация требований, средство не должно ориентироваться на
их описание. длину, формат или расположение экранных
38Техническое задание. ГОСТ 19.201-78. полей ввода-вывода (input and output
Единая система программной документации. fields); d) для каждого понятия следует
Техническое задание. Требования к использовать отдельное сообщение.
содержанию и оформлению ГОСТ 34.602-89 Сообщения не должны быть надуманными; e)
Информационная технология. Техническое переменные в сообщении должны содержать
задание на создание автоматизированной только непереводимую информацию, например
системы. ключевые слова и коды возврата; f) из
39Варианты использования. Автор: Айвар предложений не следует исключать предлоги
Якобсон (Ivar Jacobson) Вариант в целях экономии места.
использования — это формальное описание 101Культурные факторы (1). A)
взаимодействия системы и пользователя при иллюстративные материалы (например, лица,
решении конкретной задачи. Каждый ВИ животные и звуки речи) должны быть
нацелен на конкретную бизнес-цель независимыми от национальных культурных
(конкретную задачу). «Usage scenario» ? особенностей; b) следует избегать
«usage case»? «use case». использования примеров, связанных со
40Варианты использования. Краткий специфическими национальными традициями
(brief) ВИ Бессистемный (casual) ВИ или особенностями (например, праздниками,
Детальный (detailed) ВИ 1. Название банковским делом, зарплатой, спортом и
(Name). Краткое, максимально понятное, в т.Д.); C) в тексте и иллюстрациях следует
виде команды (что сделать). 2. Цель избегать использования идиоматических
(Goal). Краткая (до нескольких выражений, присущих национальному языку
предложений) характеристика задачи, документатора; d) следует избегать
которую должен в результате решить ВИ. 3. использования юмористических выражений,
Начальное состояние (Initial state). особенно каламбуров. E) следует осторожно
Формулировка условий, при которых данный использовать иронические выражения;
ВИ может быть инициирован. 4. Основной 102Культурные факторы (2). f) необходимо
сценарий (Main scenario). Сценарий — это избегать использования сленговых,
последовательность шагов, описывающая жаргонных и простонародных выражений; g)
процесс решения задачи, которой посвящен не должны использоваться упоминания первых
ВИ. 5 и т. д. — альтернативные сценарии. лиц государства; h) не следует выражать
41Варианты использования. Название: даты только в числовом виде. Месяц всегда
Отправить электронное письмо. Цель: должен быть написан полностью (например,
Отправить созданное письмо с проверкой 28 июля 1991); i) обычно следует
корректности его атрибутов. Начальное использовать двумерные представления, если
состояние: Выполнен ВИ «Создать новое международные соглашения не требуют иного
письмо» или ВИ «Создать ответ на письмо». (например, для автошин, водопроводов,
Основной сценарий: 1. Пользователь гвоздей и фотопленки); j) когда
выполняет команду отправки письма. 2. метрические величины располагаются вместе
Программа проверяет, правильно ли с величинами в других системах измерения,
заполнено поле «Адрес». 3. Если нет, из контекста должно быть понятно, какая из
программа сообщает об ошибке и отменяет величин относится к соответствующей
отправку. Конец. 4. Если да, то программа системе измерений.
проверяет, заполнено ли поле «Тема». 5. 103Выпуск. Основные этапы готовности
Если нет, программа выдает предупреждение, продукта: Реализация базовых функций
но не отменяет отправку. 6. Программа множество возможностей ещё отсутствуют,
помещает письмо в папку «Исходящие» и однако все базовые уже реализованы 2.
отсылает его. 7. После отправки программа Альфа-версия завершенный, но ещё полный
перемещает письмо в папку «Отправленные». ошибок продукт имеются практически все её
Сценарий обработки ошибок: Предусловие: функции, однако некоторые могут работать
на шаге 6 основного сценария происходит крайне нестабильно интерфейс и
ошибка отправки письма (сбой сети и т. п.) документация находятся в стадии доработки
7. Программа сообщает об ошибке и 3. Бета-версия практически законченный
предлагает сохранить текст письма в файл. продукт, в котором разработчики выполнили
8. Если пользователь согласен сохранить своими силами всё возможное тестирование
текст, выполняется ВИ «Сохранить черновик 4. Релиз приёмо-сдаточные испытания.
в файл». 104Приёмо-сдаточные испытания. Общее
42Виды применения ВИ. Как средство планирование испытаний : Разработка общей
фиксации функциональных требований на стратегии испытаний системы Календарный
этапе анализа как источник информации о график проведения испытаний планирование
постановке задачи для выполнения ресурсов планирование видов испытаний
проектирования и программной реализации планирование состава комиссии для каждого
системы для тестирования системы для испытания Детальное планирование испытаний
написания пользовательской документации. Выявить условия, демонстрирующие
43Проектирование. Хороший проектировщик функционирование системы с точки зрения
обязан полагаться на опыт, на ясное пользователей Подготовить демонстрационные
логическое мышление и на педантичную тесты подготовить демонстрационные данные
точность. Никакая магия здесь не поможет. подготовить демонстрационные сценарии
Никлаус Вирт Цель — преобразовать общие Описать программу и методику испытаний.
внешние требования к продукту в конкретные 105Контрольные бланки испытания. Название
требования к внутреннему устройству и программного продукта: Информационная
функционированию продукта. система «Сеть отелей». Название
44Объекты проектирования —виды проектных программного продукта: Информационная
требований. Физическая структура (physical система «Сеть отелей». Название
structure) Логическая структура (logical программного продукта: Информационная
structure); Алгоритмы (algorithms); система «Сеть отелей». Название
Структуры данных (data structures); программного продукта: Информационная
Пользовательский интерфейс (user система «Сеть отелей». Характеристика
interface). испытания: Заказ на бронирование места в
45Архитектурное и детальное отеле, расположенном в данном районе.
проектирование. Архитектурное Характеристика испытания: Заказ на
проектирование = эскизное проектирование = бронирование места в отеле, расположенном
концептуальное проектирование = в данном районе. Характеристика испытания:
проектирование в большом (design in large) Заказ на бронирование места в отеле,
Детальное проектирование = рабочее расположенном в данном районе.
проектирование = техническое Характеристика испытания: Заказ на
проектирование = проектирование в малом бронирование места в отеле, расположенном
(design in small). в данном районе. Дата испытания: Дата
46Архитектура. Архитектура состоит из испытания: Дата испытания: Дата испытания:
всех важных проектных решений по поводу Состав комиссии: Состав комиссии: Состав
структур программы и взаимодействий между комиссии: Состав комиссии: №. Описание
этими структурами, которые составляют теста. Ожидаемый результат. Фактический
системы Архитектура – это фундаментальная результат. 1. Неверно задан район. Выборка
организация системы, реализованная в ее не должна производиться. . 2. Район задан
компонентах, связях этих компонентов друг верно, но класс отеля назван неправильно.
с другом и внешней средой и принципах, Выборка не должна производиться. . 3.
определяющих структуру и развитие системы Область и класс отеля заданы верно. Должна
Архитектура – это разделение системы на производиться выборка. . 4. В первом
наиболее крупные составные части; некие выбранном отеле есть свободные номера. При
конструктивные решения, которые после их бронировании будет выдано подтверждение.
принятия с трудом поддаются изменению; это . 5. В первом выбранном отеле свободных
согласие в вопросе идентификации главных номеров нет. Бронирование не выполняется,
компонентов системы и способов их перейти к следующему отелю. . 6. В
взаимодействия, а также выбор таких последнем из отелей, расположенных на
решений, которые интерпретируются как территории данного района, есть свободные
основополагающие и не подлежащие изменению номера. При бронировании будет выдано
в будущем. подтверждение. . 7. Ни в одном из отелей
47Декомпозиция проектируемой системы. на территории данного района свободных
Основания декомпозиции: процедурное номеров нет. Заказ на бронирование
(алгоритмическое) и отклоняется. .
объектно-ориентированное. При 106Внедрение. Испытания. Опытная
процедурно-ориентированной декомпозиции эксплуатация. Промышленная эксплуатация.
выделяются процедуры, а при Исправления.
объектно-ориентированной — классы и 107Оценка качества ПО. Измеряй то, что
объекты. измеримо, и делай измеримым то, что нельзя
48Декомпозиция проектируемой системы. измерить. Галилео Галилей Квалиметрия:
При нисходящем проектировании дисциплина, изучающая количественную
(проектировании «сверху вниз», top-down оценку качества теоретическая:
design) проектирование начинается с математические модели прикладная:
верхнего уровня абстракции — представления конкретные видов объектов географическая
системы как «черного ящика». При педагогическая …
восходящем проектировании (проектировании 108Понятие качества. Качество программы
«снизу вверх», bottom-up design) сразу (quality) — весь объём признаков и
выделяется множество необходимых элементов характеристик программы, который относится
нижнего уровня реализации, затем над ними к её способности удовлетворять
надстраивается уровень управления. При установленным или предполагаемым
проектировании методом расширения ядра потребностям. Уровень качества
(проектировании «от центра») выделяется функционирования (level of performance) —
базовый процесс или объект (ядро), на степень, в которой удовлетворяются
котором основана вся система. потребности, представленные конкретным
Проектирование ведется одновременно «вниз» набором значений для характеристик
(для реализации ядра на низком уровне) и качества.
«вверх» (для использования ядра на верхнем 109Свойства программного средства.
уровне). Функциональные свойства Отражают
49Шаблоны проектирования. То, что мы возможности и специфику применения
называем хаосом, — просто шаблоны, которые программы и обусловливают степень её
мы не распознали. То, что мы называем соответствия своему целевому назначению.
случайным, — шаблоны, которые мы не Они характеризуют программу с точки зрения
расшифровали. Чак Паланик Кристофер того, как в действительности она
Александер (Christopher Alexander) в 1977 выполняется. Конструктивные свойства
г. предложил язык описания шаблонов для Характеризуют программу с точки зрения
плани­рования застройки городов и того, как в действительности она
конструирования зданий. Широкое сконструирована, устроена. Более или менее
распространение шаблоны проектирования ПО не зависят от её функциональных
получили после выхода в 1991 г. книги возможностей и назначения.
«банды четырёх» Эриха Гамма (Erich Gamma), 110Методы оценки свойств ПО. ГОСТ
Ричарда Хелма (Richard Helm), Ральфа 28195-89 «Оценка качества программных
Джонсона (Ralph Johnson) и Джона средств» по способам получения информации
Влиссидеса (John Vlissides) «Приёмы измерительный, регистрационный,
объектно-ориентированного проектирования. органолептический, расчётный; по
Паттерны проектирования». источникам получения информации
50Шаблоны проектирования. Шаблон традиционный, экспертный, Социологический.
(паттерн) проектирования представляет 111Номенклатура показателей качества.
собой формализованное описание часто ГОСТ Р ИСО/МЭК 9126-93. «Оценка
встречающейся задачи проектирования программной продукции. Характеристики
удачное решение данной задачи рекомендации качества и руководства по их применению»
по применению этого решения в различных Функциональные возможности (Functionality)
ситуациях. Надёжность (Reliability) Практичность
http://citforum.ru/SE/project/pattern/ (Usability) Эффективность (Efficiencies)
http://c2.com/cgi/wiki?CategoryPattern. Сопровождаемость (Maintainability)
51Шаблоны проектирования. 1. Шаблоны Мобильность (Portability).
проектирования классов/объектов 1.1. 112Описание методов программной
Структурные шаблоны проектирования инженерии. «Essence: Kernel and Language
классов/объектов 1.2. Шаблоны for Software Engineering Methods»
проектирования поведения классов/объектов («Основы: ядро и язык методов программной
1.3. Порождающие шаблоны проектирования 2. инженерии») — стандарт OMG 2013 г.,
Архитектурные системные шаблоны 2.1. созданный SEMAT. OMG (Object Management
Структурные шаблоны 2.2. Шаблоны Group): консорциум по стандартам в
управления 2.2.1. Шаблоны компьютерной индустрии, основан в 1989 г.
централизованного управления 2.2.2. SEMAT (Software Engineering Method and
Шаблоны управления, основанные на событиях Theory): консорциум по унификации теории
2.2.3. Шаблоны взаимодействия с базой программной инженерии, основан в 2009 г.
данных 3. Шаблоны интеграции корпоративных 113Ядро (Kernel). Ядро программной
информационных систем 3.1. Структурные инженерии (Software Engineering Kernel) —
шаблоны интеграции 3.2. Шаблоны по методу минимальный набор определений, который
интеграции 3.3. Шаблоны интеграции по типу выражает суть программной инженерии
обмена данными. способом, независимым от конкретных
52Анти-шаблоны (anti-patterns). практик. Альфы (Alphas) — ключевые понятия
http://www.antipatterns.com/briefing/ (essential things to work with). Типовые
http://c2.com/cgi/wiki?AntiPatternsCatalog деятельности (Activity Spaces) — ключевые
William J. Brown, Raphael C. Malveau, Hays типы деятельности (essential things to
W. McCormick III, and Thomas J. Mowbray do). Компетенции (Competencies) — ключевые
AntiPatterns: Refactoring Software, способности (the abilities needed).
Architectures, and Projects in Crisis. — 114Ядро: Альфа. Ключевой элемент, с
John Wiley & Sons, 1998. — ISBN помощью оценки состояния которого которого
0471197130. можно оценить прогресс и успешность
53Проектирование модулей. 1. Модуль есть проекта. An essential element of the
единица структуры исходного текста software engineering endeavor that is
программы, оформляемая, как правило, в relevant to an assessment of the progress
виде отдельного файла. 2. Модуль в and health of the endeavor. Alpha is an
программных проектах является единицей acronym for an Abstract-Level Progress
ком­пи­ля­ции, описания и Health Attribute.
администрирования. 3. Модуль имеет две 115Ядро: Типовая деятельность. Заготовка
логически различные части: интерфейс и (placeholder) для типовой деятельности в
реализацию. Интерфейс модуля есть набор проекте. Называет, что должно делаться, но
описаний (прототипов) функций и данных не предписывает как именно. A placeholder
модуля, доступных «извне» модуля. for something to be done in the software
Реализация модуля есть собственно engineering endeavor. A placeholder may
программный код функций и данных. consist of zero to many activities.
54Качество проектирования модулей. 116Ядро: Компетенция. Характеристика
Связность >> Зацепление. представителя стейкхолдера или члена
55Качество проектирования модулей. команды с точки зрения способности к
Достаточность интерфейса Полнота определённой работе. A characteristic of a
интерфейса. stakeholder or team member that reflects
56Проектирование интерфейса the ability to do work.
пользователя. Для большинства 117Альфы.
пользователей интерфейс вашей системы и 118Альфы.
есть ваша система. Ребекка Райордан 119Альфы (область клиента). 1.
Когнитивная психология Физиология Opportunity: The set of circumstances that
Лингвистика И др. Чтобы сделать хороший makes it appropriate to develop or change
UI, необходимо понять, как человек думает, a software system. 2. Stakeholders: The
как общается, как манипулирует предметами, people, groups, or organizations who
как запоминает и вспоминает, как affect or are affected by a software
догадывается, как учится, как видит, system.
читает и пишет. 120Альфы (область решения). 3.
57Проектирование интерфейса Requirements: What the software system
пользователя. Интерфейсом (interface) двух 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
Интерфейс пользователя (user interface) — 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
58Классификации интерфейса пользователя. 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
(character user interface, CUI) и by a team to guide and support their work.
графический интерфейс пользователя 122Стейкхолдеры: состояния.
(graphical user interface, GUI). По типу 123Возможности: состояния.
управления различают командный интерфейс и 124Требования: состояния.
визуальный интерфейс. По активной стороне 125Система: состояния.
выделяют классический интерфейс и 126Команда: состояния.
интерфейс «Мастеров» (Wizards). 127Работа: состояния.
59Характеристики интерфейса 128Технология работы: состояния.
пользователя. Дружественность 129State. Checklist. Recognized. All the
(человечность) Предсказуемость different groups of stakeholders that are,
(интуитивная понятность, очевидность). or will be, affected by the development
Простота Привлекательность (эстетичность) and operation of the software system are
Целостность. identified. There is agreement on the
60Типичные ошибки дизайна UI. stakeholder groups to be represented. At a
Непредсказуемость, неэстетичность, minimum, the stakeholders groups that
сложность, нецелостность, fund, use, support, and maintain the
недружественность Выбор неверных элементов system have been considered. The
управления Сбивающая с толку терминология responsibilities of the stakeholder
Перегруженность Идиотизм в поведении representatives have been defined.
Неверные цветовые решения Неправильные Represented. The stakeholder
сообщения Плохие метафоры. representatives have agreed to take on
61Источники ошибок дизайна UI. their responsibilities. The stakeholder
Отсутствие мотивации Работает и ладно И representatives are authorized to carry
так сойдёт Не мои проблемы Да кого это out their responsibilities. The
волнует Ложная мотивация Сделаю так collaboration approach among the
«круто», чтобы все ахнули Сделаю, как stakeholder representatives has been
никто ещё не делал А мне вот так интересно agreed. The stakeholder representatives
попробовать Плохие примеры для подражания. support and respect the team's way of
62Примеры ошибок дизайна UI. working. Involved. The stakeholder
63Примеры ошибок дизайна UI. representatives assist the team in
64Примеры ошибок дизайна UI. accordance with their responsibilities.
65Примеры ошибок дизайна UI. Вот так The stakeholder representatives provide
правильно: feedback and take part in decision making
66Примеры ошибок дизайна UI. in a timely manner. The stakeholder
67Программирование. Если отладка — representatives promptly communicate
процесс удаления ошибок, то changes that are relevant for their
программирование должно быть процессом их stakeholder groups. In Agreement. The
внесения. Эдсгер Дейкстра Стандарты stakeholder representatives have agreed
кодирования Оптимизация программы upon their minimal expectations for the
Безопасное программирование. next deployment of the new system. The
68Стандарты кодирования (1). Любой дурак stakeholder representatives are happy with
способен писать код, который может понять their involvement in the work. The
компьютер. Хорошие программисты пишут код, stakeholder representatives agree that
который может понять человек. Мартин their input is valued by the team and
Фаулер Снижение зависимости от конкретных treated with respect. The team members
разработчиков Повышение сопровождаемости agree that their input is valued by the
программ Повышение культуры stakeholder representatives and treated
программирования и снижение количества with respect. The stakeholder
ошибок. representatives agree with how their
69Стандарты кодирования (2). different priorities and perspectives are
Структурирование текста Методы being balanced to provide a clear
структурирования позволяют наглядно direction for the team. Satisfied for
выявить соподчинённость конструкций и их Deployment. The stakeholder
группирование Разрежение текста Методы representatives provide feedback on the
разрежения текста позволяют облегчить system from their stakeholder group
чтение за счёт дополнительных пробелов perspective. The stakeholder
(горизонтальное разрежение) и пустых строк representatives confirm that the system is
(вертикальное разрежение) Именование ready for deployment. Satisfied in Use.
объектов Методы именования объектов Stakeholders are using the new system and
включают системы именования переменных, providing feedback on their experiences.
типов, процедур и модулей Комментирование. The stakeholders confirm that the new
70Стандарты кодирования (3). Делайте system meets their expectations.
функции небольшими Функция должна делать 130Типовые деятельности.
только одно дело Функции должны быть 131Компетенции.
функционально простыми Избегайте 132
Технологии программирования Software engineering.pptx
http://900igr.net/kartinka/informatika/tekhnologii-programmirovanija-software-engineering-246592.html
cсылка на страницу

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

другие презентации на тему «Технологии программирования Software engineering»

«Разделы технологии» - Технология. Рассказывают о традициях разных народов, национальных праздниках и обрядах. А у нас из блестящего бисера - Необычная красота. Лоскутное шитье издавна известно многим народам. Региональные и Национальные традиции сервировки стола. И национальный и региональный Мы всегда внедряем компонент.

«Технологии» - Использование современных образовательных технологий. Фотомгновения. Повышение квалификации и профессиональная переподготовка. Классный руководитель V класса. Внеурочная деятельность обучающихся. Результаты внеурочной деятельности обучающихся. Участие в муниципальных, региональных и федеральных профессиональных конкурсах;

«Классификация языков программирования» - Никлаусом Виртом. На слайдах будут приведены вопросы с вариантами ответа. Системы программирования. Читай вопрос и выбирай ответ. Повтори классификацию языков программирования по степени детализации и способы записи алгоритмов. Денисом Ритчи. Язык программирования Pascal относится к: Язык программирования Pascal был разработан:

«История развития языков программирования» - Роль программирования в машинных командах стала уменьшаться. Метаязыки описания языков программирования. Для каждого понятия языка существует единственная метаформула (нормальная форма). Середина 50-х годов характеризуется стремительным прогрессом в области программирования. Другое направление в программировании связано с методологиями непроцедурного программирования.

«Курсы программирования» - Использование различных эффектов. Многообразие фильтров в Photoshop. Знакомство со средой программирования Pascal. Фильтры и спецэффекты. Как работать с фильтрами? Перспективы по окончанию курса. Создание многослойного изображения. Трехмерная графика 3DMax. Работа с текстом в Photoshop (ввод, редактирование форматирование символов и абзацев).

«Объектно-ориентированное программирование» - Технология нисходящего структурного программирования Появление ООП. Постановка задачи. 1. Что такое класс? Продолжение кризиса. Объект является представителем (экземпляром) какого-либо класса. Основы объектно-ориентированного программирования. Отдел 3. Метод – поведение объекта. (опять про печенье, но в форме собаки).

Программирование

31 презентация о программировании
Урок

Информатика

130 тем
Картинки
900igr.net > Презентации по информатике > Программирование > Технологии программирования Software engineering