Методо-ориентированные прикладные программы.
Данный класс включает программные продукты, обеспечивающие математические, статические и другие методы решения задач. Это методы математического программирования, решения дифференциальных уравнений, имитационного моделирования, исследования операций. Часто методо-ориентированные прикладные программы являются частью других ПО: например, MS Word позволяет проводить анализ текста и составлять различные статистики.
Офисное прикладное программное обеспечение.
К этому классу относят различные органайзеры, планировщики, программы-переводчики (словари, программы для машинного перевода текста с иностранных языков (в больших вузах есть даже целые кафедры механического перевода), OCR – программы для распознавания отсканированной информации), коммуникационные прикладные программы (ICQ-клиенты, браузеры, менеджеры электронной почты и т. д.).
Настольные издательские системы.
Программы для обеспечения компьютерной издательской деятельности. Например, Adobe Illustrator, Adobe PageMaker. Позволяет осуществлять компьютерную вёрстку книг, журналов, брошюр и пр. Поддерживает разбивку на страницы, создание заголовков, буквиц, средства подготовки иллюстраций и т. д.
Программные средства мультимедиа.
Позволяют выполнять создание и использование аудио и видео для расширения информационного пространства пользователя. Сюда включаются различные проигрыватели аудио и видео, программы создания анимации, программы для записи видео и аудио.
Системы искусственного интеллекта.
Этот класс объединяет ППО для реализации отдельных функций интеллекта человека. Здесь используются системы логического программирования, которые отличаются от систем процедурного программирования. Основные компоненты таких систем – это базы знаний, интеллектуальный интерфейс с пользователем, программы формирования логических выводов (используется алгебра логики с выводами и доказательствами). Системы искусственного интеллекта применяются для анализа задач и поддержки принятия решения, для всевозможных высоких технологий – в робототехнике, при создании автопилотов и т. д. Во время шахматных турниров между человеком и компьютером используются системы искусственного интеллекта. Даже для распознавания текста используется искусственный интеллект – сети Маркова и пр.
● ● ●
Кроме выделенных классов можно разделить прикладное программное обеспечение на 4 группы: отдельные прикладные программы, библиотеки прикладных программ, пакеты прикладных программ и интегрированные прикладные программные системы.
Как правило, отдельная программа создаётся на каком-либо языке программирования и не сложна для разработки одним разработчиком. Библиотеки прикладных программ содержат программы для решения множества различных задач, но объединяясь, позволяют решать какую-то сложную задачу. Пакеты прикладных задач направленны на решение каких-то комплексных задач: например, пакет MS Office позволяет решать рабочие задачи любого предприятия. Интегрированные же программные системы – это комплексы программ, содержащие как пакеты прикладных программ, так и отдельные программы. Пример интегрированных программных систем – AutoCAD.
СТРУКТУРА, ОСНОВНЫЕ КОМПОНЕНТЫ ППО И СОЗДАНИЕ ППО.
Основными компонентами прикладного программного обеспечения являются:
Входные языки
Предметное обеспечение
Системное обеспечение
Входные языки представляют собой средства общения пользователя с программой. Для конечного пользователя важным входным языком будет являться графический интерфейс, для администратора – какие-то системные команды, для разработчика ПО – язык программирования, на котором создаётся данное ПО.
Можно выделить следующие типы пользователей прикладного ПО:
Разработчик ПО. Осуществляет создание, модификацию и развитие прикладной программы с учётом класса решаемых задач и состава аппаратного и программного обеспечения компьютера.
Ответственный за сопровождение или техподдержка (так называемый техсаппорт). Его функции – поддержание пакета в работоспособном состоянии в условиях конкретной вычислительной системы.
Администратор. Отвечает за обеспечение доступа пользователя к прикладному ПО, за содержание баз данных и за защиту информации от несанкционированного доступа. Как правило, в отличие от техподдержки, администратор является локальным для конкретной фирмы, в то время как техподдержка является локальной для конкретного программного обеспечения.
Конечный пользователь. Обычный смертный. Тот, кто работает с прикладным ПО для решения конкретных задач. Очень важно, чтобы конечный пользователь был хотя бы способен объяснить свои цели администратору или техподдержке при возникновении каких-либо проблем. Для разработчика конечный пользователь может быть важен при тестировании разрабатываемого ПО в условиях заказчика.
Предметное обеспечение представляет собой компонент пакета прикладного ПО, отражающий особенности конкретной предметной области. Сюда относятся всевозможные алгоритмы, способы решения прикладных задач.
Системное обеспечение – это совокупность системных средств, обеспечивающих работу пользователя при решении конкретных прикладных задач (операционная система, в которой установленное конкретное прикладное ПО).
Прикладное ПО создаётся с помощью различных технологий программирования.
Краткая история развития технологий программирования.
Первый этап: стихийное программирование.
От момента появления первых компьютеров до середины 60-х годов XX века.
После первобытных ассемблеров, которые были индивидуальными для каждого компьютера, пошли FORTRAN, первые алгоритмический ALGON, а затем появились революционные подпрограммы, вызвавшие подразделение данных на глобальные и локальные.
Второй этап: 60-е – 80-е годы XX века.
Получил своё развитию структурный подход к программированию.
10.02.2012 Лекция |
Третий этап: середина 80-х – начало 90-х годов.
Развитие объектного подхода к программированию. Первый язык, поддерживающий объектно-ориентированный подход – язык Smalltalk, появившийся в 70-е годы.
Четвёртый этап: середина 90-х – наши дни.
Компонентный подход и CASE-технологии. Построение программного обеспечения из отдельных компонентов, физически отдельно существующих частей, которые взаимодействуют через стандартизованные интерфейсы. Т. е. в данный момент нужные компоненты можно купить в виде каких-либо библиотек, содержащих нужные классы, методы и пр., и встроить их в свои проекты. Развитие Outsourcing. Появление и развитие технологии OLE, развитием которой стала технология COM, определяющая общую парадигму взаимодействия программ любых типов библиотек, приложений, операционных систем и т. д., т. е. позволяет одной части ПО использовать функции, предоставляемые другой частью ПО. В рамках технологии COM появилась технология CORBA, которая использовалась для создания распределённых программ.
Развитием всего этого стала технология ActiveX, которая позволила устанавливать на компьютер удалённые элементы управления вне зависимости от операционной системы, что удобно использовать в клиентских частях приложений интернета – браузеры со встроенными прибамбасами, tweet-агенты, социальные сети и т. д.
CASE-технология (Computer Aided Software / System Engineering) – это технология программирования, позволяющая осуществлять создание и внедрение автоматизированных систем разработки и сопровождения программного обеспечения.
ГРУППА ПРОЕКТОВ ПО СОЗДАНИЮ ПО
Основная группа людей, участвующих в разработке прикладного программного обеспечения, как правило, состоит из следующих людей:
Руководитель проекта (обычно, человек с самой большой зарплатой) – координирует все действия, организует внешние и внутренние взаимодействия группы проекта, обеспечивает соблюдение сроков разработки и качества разрабатываемого ПО и его соответствие требованиям заказчика, несёт полную ответственность за результат работы.
Системный аналитик (основной функциональный и анализирующий мозг проекта) – анализирует требования к системе, разрабатывает концепцию и логику работы системы, составляет технические задания и несёт ответственность за соответствие предлагаемых решений требованиям заказчика. Подвидом системного аналитика является системный архитектор, который участвует в создании широких информационных сетей.
Разработчики – простые программисты. Реализуют принятые технические задания, отвечает за качество и сроки разрабатываемого кода и за его соответствие техническим заданиям. Обычно технические задания утверждаются с двух сторон: аналитик понаписал, разработчик одобрил или поправил.
Дизайнер – участвует в разработке концепции системы, разрабатывает её пользовательский интерфейс и принимает участие в его реализации, несёт ответственность за соблюдение фирменного стиля и требований к реализации пользовательского интерфейса. В идеале дизайнер должен иметь художественное образование, должен владеть знаниями человеко-машинных взаимодействий: как пользователь будет взаимодействовать с программой, какие контроллеры для этого нужно использовать (например, при разработке медицинского программного обеспечения или ПО для аэрокосмических областей науки).
Тестер – разрабатывает программу тестирования, осуществляет её и несёт ответственность за полноту тестирования готовых модулей и системы в целом. Каждый созданный модуль тестируется отдельно, а потом всё тестируется совместно. Тестеры должны иметь богатую практику использования ПО, установки ПО, должны уметь находить конфликты в работе ПО на разных версиях операционных систем, при тех или иных наборах установленных на ОС программ.
Технический писатель – разрабатывает документацию на проект, несёт ответственность за полноту и правильность написания справочной системы, руководства пользователя, руководства по установке, эксплуатации ПО. Как правило, работа технического писателя упрощается, если программисты правильно комментируют код.
Единственная оговорка заключается в том, что многие должности могут быть совмещены. Например, директор может быть одновременно и системным аналитиком, и дизайнером. Дизайнер может быть по совместительству техническим писателем, а сами разработчики могут быть тестерами – они могут тестировать результаты друг друга. Также дизайнер и системный аналитик могут не входить в группу постоянно.
Далее вместе с группой проекта могут работать менеджеры, маркетологи, которые будут анализировать рынок, выявлять тенденции развития программного обеспечения.
Современные проблемы разработки ПО заключаются в трудностях нахождения контакта группы проекта с заказчиком. Особенно это относится к малым, неопытным группам проекта.
КЛАССИЧЕСКИЙ ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Старейшая парадигма разработки ПО начала развиваться в 1970-е годы. Это не самая лучшая парадигма. Но она жива до сих пор. Её называют каскадной или водопадной моделью разработки ПО. Это означает, что переход на следующий этап разработки происходит только после полного завершения работы на текущем этапе. Обычно её можно представить в шести этапах:
Системный анализ
Анализ требований
Проектирование
Кодирование
Тестирование
Сопровождение
Системный анализ задаёт роль каждого элемента в создаваемом ПО и взаимодействия элементов друг с другом. На этом этапе определяются требования ко всем системным элементам, и начинается решение задачи планирования проекта по созданию ПО. Определяются объём проектных работ и их риски, необходимые трудозатраты, формируются рабочие задачи и план графика работ. Результат системного анализа переходит к анализу требований.
Анализ требований позволяет уточнить и детализировать все функции, характеристики и интерфейс каждого элемента системы. Всё это документируется в спецификации анализа. На этом этапе завершается решение задачи планирования проекта.
На этапе проектирования создаются представления архитектуры ПО, модульной структуры ПО, алгоритмической структуры ПО, структуры данных, входного и выходного интерфейса (как пользователь вводит данные, в каком виде он их получает и т. д.). Исходные данные для проектирования берутся из анализа требований.
Кодирование – самый простой этап – это перевод результатов проектирования в текст на языке программирования. Если всё было хорошо проанализировано и спроектировано, то никаких сложностей с кодированием не возникает. На этот этап отводится примерно 40% времени разработки ПО.
Тестирование – выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта. Проверяется, удобно ли работать с программой, в удобной ли форме она осуществлена, исправно ли выполняются все требования заказчика.
Сопровождение – внесение изменений в проектируемое ПО. Цели этих изменений – это исправление выявленных ошибок, которые не были исправлены на этапе тестирования, адаптация к изменениям во внешней для ПО среды (компьютеры могли поменяться за время разработки ПО, могла выйти новая версия операционной системы), усовершенствование программного обеспечения по требованиям заказчика. Все возможные изменения на этапе сопровождения должны быть прописаны в договоре, особенно это касается дополнительных требований, выполнение которых должно производиться только за отдельную плату. На этом этапе важно наличие юридической помощи.
Недостатки классического жизненного цикла:
Реальные проекты часто требуют отклонения от стандартной последовательности шагов
Цикл основан на точной формулировке исходных требований ПО (не все заказчики могут определить все требования в самом начале цикла)
Результаты проекта доступны заказчику только в конце работы (он будет иметь дело только с конечным продуктом без возможности его динамических изменений)
МАКЕТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Макетирование – это процесс создания модели требуемого программного продукта. Допустим, у заказчика есть некие требования к работе ПО. По его пожеланиям создаётся макет, который постепенно доводится до степени готовности внесением поправок и дополнительных пожеланий заказчика.
Модель может принимать одну из трёх форм:
Бумажный макет или макет на основе электронного изображения (по сути, это макет интерфейса программы с описанием выполнения программы)
Работающий макет, выполняющий некоторую часть требуемых функций
Существующая программа, характеристики которой можно улучшить. Т. е. программа уже практически создана, и дальнейшее макетирование осуществляется внесением изменений в существующую программу.
Общая схема макетирования:
Начало
проектирования
Сбор и уточнение требований
Быстрое макетирование
Построение макета
Оценка макета заказчиком
Уточнение макета
Продолжать проектирование? Если да – возврат к этапу “быстрое проектирование”. Если нет – идём дальше.
Конструирование продукта
Конец.
Одним из достоинств макетирования является уточнение всех требований к программе и решение таким образом главного недостатка классического жизненного цикла разработки ПО. Однако здесь важна хорошая работа с заказчиком, чтобы он не принял сырок макет за готовую программу.
СТРАТЕГИИ КОНСТРУИРОВАНИЯ ПО
Выделяют три стратегии конструирования прикладного программного обеспечения:
Однократный проход – аналог классического жизненного цикла
Инкрементная стратегия: в начале процесса определяются все пользовательские системные требования, далее конструирование выполняется в виде последовательности версий (похоже на макетирование)
Эволюционная стратегия: система строится в виде последовательности действий, но в начале процесса определены не все требования, которые уточняются в результате разработки версий
Инкрементная модель
Схема инкрементной модели:
Постановка 1-го инкремента
1-й инкремент:
Анализ – проектирование – кодирование – тестирование
Постановка 2-го инкремента
2-й инкремент:
Анализ – проектирование – кодирование – тестирование
Постановка 2-го инкремента
2-й инкремент:
Анализ – проектирование – кодирование – тестирование
...
В отличие от обычного макетирования, здесь на каждом инкременте получается готовый проект, но не со всеми требуемыми функциями (версии 0.001, 0.232 и т. д.).
15.02.2012 Лекция |
Быстрая разработка приложений (RAD Model – Rapid Application Development)
Модель заточена под разработку приложения в течение 60-90 дней. Это также пример применения инкрементной стратегии.
Выделяются следующие этапы:
Бизнес-моделирование.
На этом этапе моделируется информационный поток между бизнес-функциями. Здесь выясняется, как информация генерируется, кто её обрабатывает внутри предприятия или бизнес-системы.
Моделирование данных.
Результаты первого процесса отображаются в набор объектов данных, т. е. переходит на язык баз данных. Идентифицируются свойства и характеристики каждого объекта, определяются отношения между объектами. Какие классы будут содержать другие классы, какими классами будут использоваться и т. д.
Моделирование обработки.
Определяется преобразование объектов данных, обеспечивающих реализацию бизнес-функций. Описывается, как и согласно каким формулам преобразуется информация, и как это всё влияет на нашу систему, на наше приложение.
Генерация приложения.
В основном используются языки 4-го поколения, т. е. объектно-ориентированный подход. Чем больше повторно используемых компонентов, тем легче их использовать в своём приложении (они уже кем-т протестированы и обкатаны).
Тестирование и объединение.
Тестируется объединение компонентов в единую систему. В идеале программа строится из компонентов, которые уже оттестированы по-отдельности, и следует протестировать их в совокупности, высока вероятность обнаружения многих новых ошибок.
Обычно для осуществления этих этапов команда разработчиков разделяется на группы. Это позволяет ускорить процесс.
RAD-модель неприменима в условиях высоких технических рисков.
Спиральная модель.
Спиральная модель – это пример эволюционной стратегии конструирования. Эта модель очень актуальна в наши дни. Развитие проекта идёт по спирали, постепенно увеличивается масштаб проекта, улучшается результат. Основные этапы в данной модели:
Первоначальный сбор требований и планирование проекта
Повторение пункта 1 на следующих витках разработки с учётом рекомендаций заказчика
Анализ рисков
Повторение пункта 3 на следующих витках разработки с учётом реакции заказчика
Переход к комплексной системе
Создание начального макета системы
Переход на следующий уровень макета
Сконструированная система
Оценивание заказчиком
На этапе анализа рисков выясняется, сможет ли команда осуществить всё, что запланировано на первом этапе, нет ли каких-то фатальных для проекта эконмических сложностей и пр. Если анализ даёт положительный результат, переступается линия принятия решения. На каждом повторном этапе проверяется, насколько усложнились требования заказчика, выясняется, можно ли завершить проект, или он становится нереальным. Когда требования заказчика меняются, создаётся новый виток, и каждый раз команда обязана анализировать, потянет ли она такой проект или нет. Если анализ риска даёт отрицательный результат, команда сворачивает работу, чтобы не потерять ещё больше денег.
Достоинства спиральной модели:
Наиболее реальной отображается разработка ПО в виде его эволюции
Явно учитывается риск на каждом витке разработки
Используется моделирование для уменьшения риска и совершенствования программного изделия
Недостатки:
Относительная новизна модели по сравнению с другими
Повышенные требования к заказчику (он должен регулярно оценивать создаваемую систему)
Трудности контроля и управления временем разработки (неизвестно, сколько будет создано макетов и версий, сколько будет потрачено времени)
Компонентно-ориентированная модель.
Является развитием спиральной модели и конкретизирует квадрант конструирования (используется компонентно-ориентированный подход к разработке ПО).
Достоинства объектно-ориентированной модели:
Время разработки уменьшается на 30%
Стоимость разработки уменьшается до 70% (иногда дешевле купить, чем разрабатывать самому)
Производительность разработки увеличивается в 1,5 раза
Экстремальное программирование.
Д/з: самостоятельно найти и изучить модель “экстремальное программирование”, которая идеально подходит для разработки курсовых и дипломных работ студентов |
ОЦЕНКА КАЧЕСТВА ПРОЦЕССА СОЗДАНИЯ ПО
Качество любой продукции оценивается некими контролирующими организациями – аккредитация, сертификация, ГОСТ, ТУ, ISO и т. д.
ISO 9000 – 9004 – международный стандарт качества, описывающий требования к разной продукции. Однако его нечасто применяют к ПО.
Совокупность критериев оценки зрелости организации-разработчика и рецепты улучшения существующих процессов создания ПО представляет собой стандарт оценки качества СММ. Этот стандарт разрабатывался для правительства США, который позволял выбирать наиболее лучших поставщиков ПО для каких-то государственных целей. Эта методика оказалась подходящей для оценки любой организации-разработчика и стала международным стандартом. В отличие от ISO, в стандарте СММ выставлены не только требования, но и рекомендации по улучшению.
Стандарт СММ включает следующие уровни:
Начальный уровень. Самый базовый уровень для любого разработчика ПО. Нет стабильных условий для создания качественно ПО, результат любого проекта целиком и полностью зависит от личных качеств менеджера или опыта программистов. Причём успех в одном проекте может быть повторён только в случае тех же менеджеров и программистов на следующий проект. Если эти менеджеры и программисты уходят с предприятия, резко снижается качество производимых программных продуктов. В стрессовых ситуациях (сжатые сроки, выход из бюджета) процесс разработки сводится к написанию кода и его минимальному тестированию. Одним из самых ярких примеров начального уровня разработчика ПО являются все фирмы города Нижневартовска, которые пытаются создавать своё ПО.
Повторяемый уровень (Repeatable level). На предприятии внедрены технологии управления проектами. Накопленный опыт используется в планировании и управлении проектами. Существуют стандарты на разрабатываемое ПО и спецгруппа обеспечения качества. В случае необходимости фирма может организация может взаимодействовать с субподрядчиками (аутсорсинг). Однако в критических ситуациях процесс имеет тенденцию скатываться на начальный уровень – опять стихийное программирование, хаос.
Определённый уровень (Defined level). Начиная с этого уровня, фирма становится серьёзным разработчиком ПО. Стандартный процесс создания и сопровождения ПО полностью документирован, включая разработку и управления проектами. В процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания перехода на новые технологии существует специальная группа. Обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников, ведь программирование – одна из областей занятости, в которой невозможно оставаться профессионалом, не продолжая обучение и совершенствование своих навыков. Начиная с этого уровня, организация перестаёт зависеть от качеств конкретных разработчиков, и процесс разработки больше не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.
Управляемый уровень (Managed level). В организации устанавливаются количественные показатели качества как на программные продукты, так и на процесс в целом. Более совершенное управление проектом достигается за счёт уменьшения отклонения различных показателей проекта. В предприятии очень много занятых менеджеров. Их может быть даже больше чем программистов. Но таковы правила современного мира.
Оптимизирующий уровень (optimizing level). Мероприятия по улучшению применяются не только к существующим проектам, но и для оценки ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки и дефекты Должны вестись работы по уменьшению стоимости разработки ПО, например, с помощью создания повторного использования компонентов. Всего около 50 фирм или их подразделений в мире сертифицировано на это уровень. В России есть такая фирма – LuxeSoft.
УПРАВЛЕНИЕ РИСКОМ
Риск – это возможность опасности, неудачи.
Формула
определения риска при создании ПО:
– вероятность неудовлетворительного
результата
– потеря при неудовлетворительном
результате
Управление риском включает 6 действий:
Идентификация риска – выявление элементов риска в проекте
Анализ риска – оценка вероятности и величины потери по каждому элементу риска
Ранжирование риска – упорядочение элементов риска по степени их влияния
Планирования управления риском – подготовка к работе с каждым элементом риска
Разрешение риска – устранение или разрешение элементов риска
Наблюдение риска – отслеживание динамики элементов риска, выполнение корректирующих действий
Категории источников риска:
Проектный риск. Источники:
Выбор бюджета, плана, человеческих ресурсов программного проекта.
Формирование требований к программному продукту.
Сложность, размер и структура программного проекта.
Методика взаимодействия с заказчиком.
Обычно в России хотят получить хорошее ПО за низкие деньги, не понимая, что разработка программного обеспечения – это мероприятие космических масштабов. Поэтому если от вас хотят программное обеспечение по автоматизации управления атомной станцией, а платят, как за тетрис, значит, заказчик посылается КЕМ. Также к проектным рискам относится неверное понимание требований заказчика, неверное распределение бюджета и времени, плохая структура программ.
Технический риск. Источники:
Трудности проектирования, реализация, формирования интерфейса, тестирования и сопровождения.
Неточность спецификаций (неточность технических заданий для программистов и пр.)
Техническая неопределённость или отсталость принятого решения (когда проект основан на предыдущей технологии, которая уже отходит; очень много фирм потеряли деньги, не заметив появления Android и продолжая создание ПО для предыдущих мобильных ОС).
Коммерческий риск. Очень редко зависит от программистов, чаще зависит от менеджеров.
Создание продукта, не требующегося на рынке (такое бывает, когда проект создаётся не по заказу, а предпринимается попытка опередить требования, ложное чутьё).
Создание продукта, опережающего требования рынка (придётся ждать ни один год, чтобы за программу кто-то начал платить, а к тому моменту другая фирма-разработчки оценит ваш продукт и создаст более совершенный).
Потеря финансирования.
Для определения рисков составляется проверочный список из 10 самых главных элементов программного риска:
Дефицит персонала
Нереальное расписание и бюджет
Разработка неправильных функций и характеристик
Разработка неправильного пользовательского интерфейса
Слишком дорогое обрамление
Интенсивный поток изменений требований
Дефицит поставляемых компонентов
Недостатки в задачах, разрабатываемых смежниками (при аутсорсинге)
Дефицит производительности при работе в реальном времени
Деформирование научных возможностей (применение неверных научных теорий или недостаток верных).
Принцип Парето “80/20” для ранжирования рисков: 80% всего проектного риска приходятся на долю 20% от общего количества элементов риска. Т. е. при ранжировании рисков мы выясняем, какие риски нужно отслеживать внимательнее, какие – нет.
АНАЛИЗ И МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
Пять признаков сложной системы:
Первый признак.
Сложные системы часто являются иерархическими и стоят из взаимозависимых подсистем, которые в свою очередь также могут быть разделены на подсистемы, и т. д., вплоть до самого низкого уровня.
Второй признак.
Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен и в большой степени оставляется на усмотрение исследователя. Т. е. если спросить двух разных людей, какие компоненты в системе являются элементарными, они могут дать разные ответы.
Третий признак.
Внутрикомпонентная связь обычно сильнее, чем связь между компонентными. Это обстоятельство позволяет отделять “высокочастотные” взаимодействия внутри компонентов от “низкочастотных”.
Четвёртый признак.
Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных.
Пятый признак.
Любая работающая сложная система является результатом развития работавшей более простой системы.
20.02.2012 Лекция |
Цель проектирования – это создание системы, которая:
Удовлетворяет заданным возможно, неформальным) функциональным спецификациям: система должна быть красивой, но никто точно не определит, что означает красивость, поэтому это и называется неформальной спецификацией
Согласована с ограничениями, накладываемыми оборудованием
Удовлетворяет явным и неявным требованиям по эксплуатационным качествам и ресурсопотреблению
Удовлетворяет явным и неявным критериям дизайна продукта
Удовлетворяет требованиям и самому процессу разработки, таким как, например, продолжительность и стоимость, а также привлечение дополнительных инструментальных средств
Кратко: цель проектирования – это сделать из сложной системы простую.
В итоге должна получиться ясная и относительно простая внутренняя структура система, которую можно назвать архитектурой системы.
АНАЛИЗ СИСТЕМ
Модель системы – это формальное описание системы, в котором выделены основные объекты, составляющие систему и отношения между этими объектам.
Почти все крупные программные продукты – это модели. Adobe Photoshop – это модель художника в паре с фотографом. MS Word – это модель секретаря в паре с верстальщиком и корректором.
Цель анализа – обеспечить правильную постановку и адекватное понимание рассматриваемой прикладной задачи, что предварительно спроектированная системы сможет удовлетворить требования заказчика.
В результате анализа строится система модели, которая отражает структурный и оценочный аспекты функционирования предметной области.
Структурный аспект предполагает построение:
Объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области
Функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах
Структуры управления
Организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах
Технической структуры, описывающей топологию расположения и способы коммуникации
Главный критерий адекватности структурной модели предметной области – функциональная полнота разрабатываемой информационной системы.
Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями Эффективности автоматизируемых процессов, к которым относятся:
Время решения задач
Стоимостные затраты на обработку данных
Надёжность процессов
Косвенные показатели эффективности (объёмы производства, производительность труда, оборачиваемость капитала, рентабельность)
Модели строятся на трёх уровнях:
Внешний уровень: определение требований. Модель отвечает на вопрос, что должна делать система. Определяется состав основных компонентов системы – объектов, функций, событий, организационных единиц, технических средств (например, сырьё и материалы, полуфабрикаты, услуги, заказы, накладные, счета и т. д.). В функциональной структуре здесь определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15-20. В структуре управления здесь определяется список внешних событий, вызываемых взаимодействием предприятия с внешней средой, и список целевых установок (соответствие ГОСТ’ам, стандартам ISO и т. д.). В организационной структуре здесь определяются со структурной модели предприятия в виде иерархии подчинения организационных единиц или списков взаимодействующих подразделений. В технической структуре здесь определяются типы технических средств обработки данных и их размещение по структурным подразделениям.
Концептуальный уровень: спецификация требований. Модель отвечает на вопрос – как должна функционировать система? Уточняется состав классов объектов, определяются их атрибуты и взаимосвязи. В функциональной структуре здесь происходит построение иерархии взаимосвязанных функций. В структуре управления здесь устанавливаются бизнес-правила, определяющие условия вызова функций при возникновении событий и достижении состояний объектов. В организационной структуре здесь для каждого подразделения задаётся организационно-штатная структура должностей (ролей персонала). В технической структуре здесь определяются способы коммуникаций между техническими комплексами структурных подразделений: физическое перемещение документов, машинных носителей, обмен информацией по каналам связи и т. д.
Внутренний уровень: реализация требований. Модель отвечает на вопрос, с помощью каких программно-технических средств реализуются требования к системе. Результаты предыдущего уровня отображаются в виде файлов базы данных, входных или выходных данных информационной системы. Здесь отображается структура информационного процесса в компьютере. В структуре управления здесь выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей. В организационной структуре здесь определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы. В технической структуре строится модель “клиент-серверной” архитектуры вычислительной сети.
МЕТОДИКИ АНАЛИЗА СИСТЕМ.
СТРУКТУРНЫЙ АНАЛИЗ
Это метод исследования системы, которое начинается с её общего обзора, а затем детализируется, приобретая иерархическую структуру с всё большим числом уровней.
Ключевые понятия структурного анализа:
Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.
Функция – это совокупность операций, сгруппированных по определённому признаку.
Бизнес-процесс – связанная совокупность функций, представляющая ценность для потребителя, в ходе выполнения которой потребляются определённые ресурсы и создаётся продукт (предмет, услуга, научное открытие, идея).
Подпроцесс – это бизнес-процесс, являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя
Бизнес-модель – структурированное графическое описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую и предполагаемую деятельность предприятия.
Существует две методологии структурного моделирования предметной области: функционально-ориентированная (IDEF0) и объектно-ориентированная (UML).
Функциональная методика IDEF0 состоит из функционального блока, интерфейсной дуги, декомпозиции, глоссария.
Функциональный блок – это прямоугольник, каждая из сторон которого имеет своё значение:
Верхняя сторона имеет значение “Управление”
Левая сторона – “Вход”
Правая сторона – “Выход”
Нижняя сторона – “Механизм” (машина или человек, выполняющий операцию)
Интерфейсная дуга – это стрелка или поток. Может отображать как реальные объекты, так и просто влияние на функциональный блок.
Декомпозиция – это разбиение сложного процесса на составляющие функции.
Глоссарий – набор всех понятий, которые используются в системе.
Объектно-ориентированная методика UML – это методика, в основе которой лежит объектная декомпозиция. Схематично UML выглядит так:
Объектная декомпозиция
Объекты и связи между ними Обмен сообщениями между объектами
UML использует следующие известные нам принципы:
Абстрагирование
Инкапсуляция
Модульность
Иерархия (у всех классов есть один общий предок, и какой бы класс мы ни использовали, он так или иначе является наследником какого-либо более старшего класса)
Типизация
Параллелизм
Устойчивость
Основными понятиями объектно-ориентированной методики являются объект и класс.
Объект – это предмет или явление, имеющее чётко определённое поведение и обладающее состоянием, поведением и индивидуальностью. Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств.
На этапе анализа и ранних стадиях проектирования решаются две основные задачи: выявление классов и объектов, составляющих словарь предметной области; построение структур, обеспечивающих взаимодействие объектов, при котором выполняются требования задачи.
Для выявления классов применяется классификация.
Виды классификаций:
Классификация категоризация
Концептуальная кластеризация
Теория прототипов
Достоинства объектно-ориентированного подхода:
Объектная декомпозиция даёт возможность создавать модели меньшего размера путём использования общих механизмов, обеспечивающих необходимую экономию выразительных средств
Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования, что ведёт к созданию среды разработки и переходу к сборочному созданию моделей из уже созданных блоков (классов)
Объектная декомпозиция позволяет избежать создания сложных моделей
Объектная модель наиболее естественная – люди живут объектами
ПРОЕКТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ
Пользовательский интерфейс – это совокупность программно-аппаратных средств, обеспечивающих взаимодействие пользователя с компьютером. Основу такого взаимодействия составляют диалоги.
Диалог – это регламентированный обмен информацией между человеком и компьютером, осуществляемый в реальном масштабе времени и направленный на совместное решение конкретной задачи: обмен информацией и координация действий.
Каждый диалог состоит из отдельных процессов ввода-вывода, которые физически обеспечивают связь пользователя и компьютера.
Обмен информацией осуществляется передачей сообщений и управляющих сигналов. Сообщение – это порция информации, участвующая в диалоговом обмене.
Различают входные сообщения, которые генерируются человеком с помощью средств ввода: клавиатуры, манипуляторов, например мыши и т. п; и выходные сообщения, которые генерируются компьютером в виде текстов, звуковых сигналов, изображений на мониторе вибрации геймпада и т. д.
Три модели пользовательского интерфейса:
Модель программиста
Модель пользователя
Программная модель
11.03.2012 Лекция |
Модель программиста учитывает функциональность, эффективность, технологичность, внутренняя стойкость и другие не связанные с удобством пользователя характеристики программного обеспечения.
Модель пользователя базируется на особенностях опыта конкретных пользователей, который характеризуется уровнем подготовки в предметной области разрабатываемой ИС, интуитивными моделями выполнения операций в этой предметной области, уровнем подготовки в области владения компьютером, устоявшимися стереотипами работы с компьютером.
Основные критерии оценки интерфейса пользователя:
Простота освоения и запоминания операций системы (оценивают время освоения и продолжительность сохранения информации в памяти)
Скорость достижения результатов при использовании системы (определяется количеством вводимых или выбираемых мышью команд и настроек)
Субъективная удовлетворённость при эксплуатации системы (удобство работы, утомляемость).
Как правило, пользователь оценивает программу по удобству её интерфейса, а не по тому, насколько хорошо она работает. Если пользователю неудобно работать с вашей программой, то в условиях свободного интернета ему очень просто отказаться от неё в пользу более удобной, пусть и не настолько функциональной.
ДИЗАЙН ИНТЕРФЕЙСА
Дизайн интерфейса состоит из трёх этапов: первоначальное проектирование, создание прототипа, тестирование и модификация прототипа. При создании интерфейса большая роль уделяется техническому писателю – создателю документации. Если интерфейс качественный, техническому писателю проще его описать, а если же технический писатель сталкивается со сложностями при описании, значит, интерфейс слишком замудрён. Документация есть часть интерфейса, и чем сложнее ПО, тем большую часть в нём должна составлять документация.
Первоначальное проектирование
Включает в себя 7 этапов:
Определение необходимой функциональности системы
Прилив вдохновения
Создание пользовательских сценариев
Проектирование общей структуры
Конструирование отдельных блоков
Создание глоссария
Сбор и начальная проверка полной схемы системы
Определение необходимой функциональности базируется на двух видах анализа – на анализе целей пользователя и анализе действий пользователя. Это приводит к следующим выводам: людям не нужны инструменты сами по себе, нужны лишь результаты их работы; для достижения одного и того же результата можно совершить различные действия.
Прилив вдохновения: чем раньше – тем лучше. Это когда из анализа, проведённого на первом этапе, разработчик начинает представлять, как это всё будет выглядеть, в каких цветах и т. д.
Цель создание пользовательских сценариев – написать словесное описание взаимодействия пользователя с системой, не конкретизируя, как конкретно будет происходить взаимодействие, но уделяя как можно больше внимания всем целям пользователей. Например, пусть разрабатывается программа почтовый клиент. Вот возможный вариант пользовательского сценария:
-
Елизавета Андреевна запускает почтовую программу, вручную скачивает из почтового ящика несколько писем, читает все сообщения, часть удаляет, на одно из них отвечает, а затем выключает программу.
Второй сценарий:
-
Еремей Карапетович делает активным окно уже открытой программы, скачивает все сообщения, одно сообщение пересылает другу, одно из них печатает, а затем переключается на другую задачу.
Третий сценарий:
-
Пришло новое сообщение, и Джамиля Андреевна воспринимает оповещающий индикатор и сразу открывает новое сообщение, после прочтения перемещает сообщение в новую папку, а затем закрывает окно программы.
Польза таких сценариев очевидна: в дальнейшем сценарии могут пригодиться для последующего тестирования, да и сам факт написания сценария приводит к лучшему пониманию устройства проектируемой системы, побуждая сразу же оптимизировать будущее взаимодействие.
Пользуясь информацией, собранной на предыдущих этапах, необходимо создать общую структуру системы (“вид с высоты птичьего полёта”), т. е. выделить отдельные функциональные блоки и определить, как именно эти блоки связываются между собой. Проектирование общей структуры состоит из двух параллельно происходящих процессов: выделение независимых блоков и определения связи между ними. Если проектируется сайт, в завершении необходимо также создать схему навигации.
Конструирование отдельных блоков – это создание всех экранов системы (экран – отдельное, отличающееся от других, визуальное состояние системы).
Существует три основных вида связи между блоками: логическая связь, связь по представлению пользователя и процессуальная связь. Логическая связь определяет взаимодействие между фрагментами системы с точки зрения разработчика. Процессуальная связь – это естественная связь по описываемой предметной области.
Для проектирования отдельных блоков можно использовать дополнительные вспомогательные методики. Например, методику GOMS (Goals, Operators, Methods and Selection rules – цели, операторы, методы и правила их выбора). Это метод оценки интерфейса, позволяющий быстро выбрать лучший по скорости работы пользователя вариант. Вот некоторые правила GOMS:
-
Действие
Затрачиваемое время
Нажатие на клавишу клавиатуры, включая Alt, Ctrl и Shift
0,28 сек
Нажатие на кнопку мыши
0,1 сек
Перемещение курсора мыши
1,1 сек
Взятие или бросание мыши
0,4 сек
Продолжительность выбора действия
1,2 сек
Время реакции системы
От 0,1 до бесконечности (для базовых операций, таких как работа с меню, это время можно не учитывать, т. к. с момента создания метода производительность компьютеров многократно возросла)
Для упрощения логики работы системы вместе с методикой GOMS используется адаптивная функциональность. Она делает работу пользователя более простой и естественной. На вопрос о том, как определить, какие фрагменты и функции системы должны быть адаптивными, может дать ответ только детальный анализ взаимодействия пользователей с системой. Помочь здесь может только тестирование интерфейса на пользователях. Примером адаптивной функциональности является, например, запрос о сохранении внесённых изменений при нажатии кнопки “Закрыть”. Другим примером может быть телевизионный пульт: выключить телевизор можно нажатием на одну кнопку, а включить можно разными способами – нажатием на кнопку номера канала, нажатием на кнопку переключения канала и т. д.
Глоссарий фиксирует все используемые в системе уникальные понятия (например, тексты с кнопок, названия элементов и окон, названия режимов и т. д.). После этого получившийся список служит для улучшения самих понятий в системе. Например, все слова сводятся к односложным или делаются максимально короткими, проверяется, не называется ли одно и то же понятие по-разному в разных местах, стиль текста по возможности или необходимости сводится к деловому, на кнопках основных команд глаголы ставятся в инфинитиве: Открыть, Сохранить и т. д.
Сбор полной схемы системы – это в основном экраны программы или сайта с указанием всех возможных переходов. В конечном счёте такая схема показывает всю структуру программы или сайта и детальное описание всех действий, которые приводят к переходу на следующие экраны.
И последний этап – проверка интерфейса. Здесь используются экспертная оценка и построение прототипа. При экспертной оценке приглашаются эксперты в данной предметной области – специалисты, чья работа связана с описываемыми в вашей программе процессами.
Правила экспертной оценки:
Количество экспертов должно быть больше единицы (разные люди замечают разные ошибки)
Лучше привлекать несколько экспертов не одновременно, а последовательно (один эксперт высказался о недостатках, мы недостатки исправили и пригласили уже другого эксперта, он сможет найти что-то новое)
Чем больше информации о проектируемой системе будет предоставлено эксперту, тем глубже проблемы он сможет выявить
Нельзя требовать от эксперта работы по весу или количеству (не надо требовать 10 страничный доклад по 1000 рублей за страницу – эксперт просто нальёт туда воду)
На следующей лекции рассматривается построение прототипа.
15.03.2012 Подготовка к лабораторной работе №1 и обсуждение контрольной работы |
Темы для контрольной работы:
Офисные программы (Морозов и Билиенко)
Работа с векторной графикой
Работа с растровой графикой (Арсланов и Искандаров)
Работа с 3D-графикой (Жданов и Донцов)
Среды интегрированной разработки – IDE (Коноплёв и Хорольский)
Работа со звуком (Жуков)
Моя тема – сравнение программных пакетов работы с растровой графикой. Оптимальный выбор: сравнение пакетов Adobe Photoshop и GIMP.
Начать работу с указания, какой программный пакет платный, какой бесплатный, какой из них когда вышел и где используется.
Цель работы – провести сравнительный анализ нескольких программных пакетов по следующим пунктам:
Наличие или отсутствие тех или иных функций в программных пакетах. Сравнение способов реализации одних и тех же функций в разных пакетах, если таковые существуют.
Сравнение интерфейса – юзабилити
Сравнение поддерживаемых форматов
Платный пакет или бесплатный
Обязательно приложить субъективное мнение в отношении удобства работы
Итог работы: выступление с презентацией. Обязательна съёмка скриншотов. Можно снимать видео.
ЛАБОРАТОРНАЯ РАБОТА №1. ЧАСТЬ 1.
СОЗДАНИЕ БИЗНЕС-ОБЪЕКТНОЙ МОДЕЛИ
Для проектирования ПО удобно использовать специализированные программные средства.
UML – Unified Modeling Language (Унифицированный язык моделирования) является стандартом для создания модели программного обеспечения. Это графический язык, который описывает создаваемое ПО с помощью графических нотаций, т. е. изображений. Графические нотации объединяются в диаграммы, которые показывают части будущего ПО.
Первым этапом проектирования ПО является моделирование бизнес-процессов. Объектом моделирования бизнес-процессов является деятельность организации как системы. При этом исследуется структура организации, роли сотрудников в организации и взаимосвязи между сотрудниками, а также рабочие потоки в организации в целом. При бизнес-моделировании используются следующие концептуальные понятия: бизнес-роль (Business actor), сотрудник (Business worker), бизнес-вариант использования (Business use-case), диаграмма бизнес-вариантов использования, бизнес-сущность (Business entity), диаграмма деятельности.
Качество выполнения первой лабораторной напрямую влияет на качество выполнения следующей, т. к. каждая следующая лабораторная использует результаты и выводы, достигнутые во время выполнения предыдущей.
Бизнес-роль – это любой человек или подразделение (организация), которые являются внешними по отношению к моделируемой (исследуемой) организации, но взаимодействует с ней, изображается в виде человечка с косой чертой и подписью, например, “клиент”.
Сотрудник – это роль в любой организации, но не должность. Обозначается в виде вписанного в круг человечка с подписью, например, “менеджер”. При исследовании сотрудника ищут ответы на следующие вопросы: каковы ответственности сотрудника, какую квалификацию он должен иметь для исполнения своей роли, с какими сотрудниками он взаимодействует, в каких бизнес-потоках он участвует и каковы его обязанности в этих потоках.
Бизнес-вариант использования (иногда бизнес-прецедент) – это группа связанных рабочих потоков внутри организации, предоставляющая данные для бизнес-роли. Набор всех бизнес-вариантов использования для организации должен полностью описывать бизнес внутри этой организации. Обозначается в виде перечёркнутого овала с подписью внутри или снаружи. Название бизнес-варианта использования обычно состоит из глагола и существительного, например, “Пополнить счёт”, “Назначить цену”, “Расставить товар”, “Получить скидку”.
На диаграмме бизнес-вариантов использования отображаются все бизнес-роли, все сотрудники, все бизнес-варианты использования и отношения между ними. Причём последнее – самое главное. Отношения обозначаются в виде стрелок.
Задание к первой части первой лабораторной работы: составить диаграмму бизнес-вариантов использования по своей задаче. Задачи: регистрация студентов на дополнительные платные курсы в каком-либо учебном заведении, терминалы по продаже электронных авиа-билетов.
Работать будем в системе Visual Paradigm. Fullscreen – F11.
Работа проходит по вариантам. Наш вариант – создание авиакассы
20.03.2012 Подготовка ко второй части лабораторной работе №1 |
ЛАБОРАТОРНАЯ РАБОТА №1. ЧАСТЬ 2.
ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ
Диаграммы деятельности (Activity Diagram) показывают графической форме этапы рабочего процесса, последовательность операций и тех, кто отвечает за их выполнение. Создаются они из диаграмм вариантов использования (диаграмм прецедентов).
Основные элементы этой диаграммы:
Дорожки (Swimlane, плавательная дорожка), показывающие ответственности за выполняемую задачу.
Деятельности, демонстрирующие этапы рабочих потоков.
Действия, показывающие шаги в пределах деятельности. Изображаются в виде скруглённых прямоугольников.
Бизнес-объекты (Object Node), являющиеся сущностями. Обозначаются квадратом с названием объекта и состоянием объекта. Состояние может изменяться в процессе или в результате выполнения различных деятельностей.
Переходы, показывающие движение рабочего потока между деятельностями. Обозначаются направленными стрелками.
Точки принятия решений. Изображаются в виде ромба.
Синхронизация, иллюстрирующая два или более одновременных этапа в пределах рабочего потока. Изображается вертикальными, либо горизонтальными линиями. Обязательно присутствует входная (Fork Node) – разделение потоков – и выходная синхронизация (Join Note) – соединение потоков.
Исходное состояние (Initial Node) и конечное состояние (Final Note). Обозначаются жирными точками.
Задание: создать диаграммы деятельности для всех созданных usecase’ов.
|
ЛАБОРАТОРНАЯ РАБОТА №2. ЧАСТЬ 1.
РАЗРАБОТКА ТРЕБОВАНИЯ К СИСТЕМЕ
Основу составляет диаграмма прецедентов или диаграмма usecase’ов. Этот вид диаграмм позволяет создать список операций или функций, которые выполняет система. По сути, в этой диаграмме у нас расписывается всё, что относится конкретно к нашему ПО. На этой диаграмме изображаются действующие лица и прецеденты.
Действующие лица – это все, кто взаимодействует с разрабатываемой системой. Это может быть другой пользователь, другая система и время. Время является действующим лицом, потому что, например, можно поставить таймер, по истечению которого система будет выполнять резервное копирование, или, к примеру, будет забирать электронную почту с сервера.
Прецедент, или usecase, или вариант использования – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-либо действующего лица.
Вопросы, которые помогают создавать систему для выявления пользователей:
Для каждого пользователя выясняют, как он будет пользоваться системой
Будет ли он работать с информацией
Будет ли он информировать систему о внешних событиях
Должна ли система уведомлять его о каких-либо изменениях или событиях
Для выявления прецедентов:
Существует ли для любого функционального требования хотя бы один прецедент
Какую информацию предоставляет системе каждый пользователь, какую информацию получит от Системы каждый пользователь
Выявлены ли все действующие лица
Обслуживающие систему учтены ли все внешние системы, с которыми взаимодействует разрабатываемая система
какую информацию наша система будет получать от внешних систем, и какую будет отправлять им
Элементы диаграммы связываются между собой отношениями.
Между действующими лицами возможны отношения обобщения и генерализации (наследование). Если у нас есть действующее лицо “пользователь”, который может только просматривать информацию, то его функции может наследовать действующее лицо “зарегистрированный пользователь” – в его функции также включается просмотр информации, но добавляются свои функции. Такие отношения обозначаются сплошной стрелкой с наконечником, проведённой от класса-наследника к классу-потомку.
Между действующим лицом и usecase’ом возможны отношения ассоциации, изображаемые обычной стрелкой или обычной линией.
Отношения между прецедентами:
Отношения обобщения (наследования), когда деятельность одного прецедента наследуется другим прецедентом с добавлением своих свойств. Эта операция используется редко.
Включающие отношения. Изображаются в виде стрелки с надписью “Include”, которая следует от главного прецедента к дополнительному. Позволяет одному прецеденту предоставлять свои функции другому прецеденту. Например, оформление заказа предоставляет функцию выбора способа доставки. Этот вид отношения выполняется всегда, т. е. при оформлении заказа всегда требуется выяснить, каким способом товар будет доставлен.
Расширяющие отношения. Позволяют одному прецеденту дополнить свою функциональность за счёт другого. Выполняются в каких-либо исключительных ситуациях, т. е. не всегда. Изображаются в виде пунктирной стрелки с надписью “Extend”, которая следует от дополнительного к главному. Например, при просмотре заказов покупатель может отменить какой-то из сделанных заказов, а может не отменить. Когда пользователь просматривает каталог, покупатель может оформить заказ, а незарегистрированный пользователь – не может.
Задание: построить usecase-модель создаваемой системы.
В Visual Paradigm создаём привычную Use Case Diagram, но теперь не заботимся об установке флажков “Business Diagram”. Все элементы отныне рисуем без косых черт.
25.04.2012 Лекция |
ПОСТРОЕНИЕ ПРОТОТИПА
Обычно прототип строят поэтапно, с каждым этапом усложняя. Сначала анализируется единообразие системы. Затем одна за другой создаются четыре версии прототипа:
Создаётся бумажный вариант интерфейса. Интерфейс может безболезненно пережить наибольшее количество версий именно в бумажном варианте.
Презентация. Интерфейс реализуется в какой-нибудь презентационной программе. Каждый экран интерфейса получает отдельный слайд. Результат нажатия на активные элементы интерфейса имитируется переходами между слайдами. Достоинства версии: имитация взаимодействия с конечным пользователем.
Третья версия – реально выглядящая, созданная в реальной среде разработки, но лишённая функциональности и алгоритмов. На этом этапе рассматриваются возможности самой среды по созданию интерфейса, а также проверяется скорость работы с интерфейсом.
Четвёртая версия – обычно самая последняя и самая трудная в исправлении – создаётся в реальной среде разработке с добавлением реально обрабатываемых данных, которые следует брать у заказчика. В последних вариантах четвёртой версии подключается вся функциональность системы.
ТЕСТИРОВАНИЕ И МОДИФИКАЦИЯ ПРОТОТИПОВ
Тестирование интерфейса позволяет определить слабые места интерфейса, но практически не позволяет обнаружить сильные стороны интерфейсы. Существует три основных способа тестирования интерфейса: проверка посредством наблюдения за пользователем, мыслим вслух, проверка качества восприятия.
Во всех способах действуют четыре основных правила:
Тестирование на одном пользователе позволяет найти около 60% ошибок. Следует привлекать несколько разных тестеров с разным характером восприятия: люди выполняют одну и ту же задачу по-разному, и следовательно, могут находить разные ошибки.
По возможности всегда оставлять тестера одного. Наблюдение стоит организовывать так, чтобы не нарушать комфорт тестера.
Нельзя прерывать тестера до тех пор, пока он не закончит работу программы (пока не выполнит выданное ему задание).
Постановка чётко определённой задачи тестирования. Например, для тестирования главной области окна программы тестеру следует выдать одно задание, для тестирования каких-либо второстепенных окон – другое задание и т. д.
Проверка посредством наблюдения за пользователем проходит следующим образом:
Пользователю выдаётся задание
Он его выполняет
Его действия фиксируются для дальнейшего анализа с помощью записи изображения с экрана (лучше всего видео, чтобы можно было отслеживать даже непонятные движения мыши по экрану)
Данный метод исключительно полезен для выявления неоднозначности элементов интерфейса, а также для измерения времени выполнения каких-либо задач пользователем, т. е. для оценки производительности работы пользователя.
Этап “Мыслим вслух” похож на предыдущий, но тестера просят комментировать свои действия вслух. Тестер сможет поделиться с разработчиками своими мыслями.
Проверка качества восприятия позволяет определить, насколько легко интерфейсу обучиться. Этот этап перешёл в тестирование ПО из психологии и социологии. Методика данного тестирования:
Пользователю даётся задание, связанное, например, с каким-либо отдельным диалоговым окном
Пользователь его выполняет
Через несколько минут его просят нарисовать только что увиденное окно, после чего рисунок сравнивают с оригиналом
Пользователь всегда в основном запоминает то, что ему кажется актуальным в процессе работы, а также то, что показалось ему интересным или нестандартным. В этом способе срабатывает ограничение на объём кратковременной памяти человека (не стоит просить пользователя нарисовать 150 разных диалоговых окон сразу).
СПРАВОЧНАЯ СИСТЕМА
Виды справок:
Базовая справка
Обзорная справка
Справка предметной области
Процедурная справка
Контекстная справка
Справка состояния
Сообщения об ошибках
Базовая справка объясняет пользователю сущность назначение системы. Обычно должна сработать только один раз, объясняя пользователю зачем система нужна. Не всегда требуется для ПО, зато почти требуется для сайтов.
Обзорная справка рекламирует функции системы. Также обычно срабатывает один раз. Нужна и ПО, и сайтам. Оптимальный вариант – следить за действиями пользователя и показывать ему короткие рекламы типа “А вы знаете, что...” в случае заранее определённых действий пользователя.
Справка предметной области отвечает на вопрос “Как сделать хорошо?”. Поскольку пользователи зачастую не владеют знаниями предметной области, необходимо снабжать их этими знаниями на ходу. При этом действуют два правила:
Во-первых, пользователи ненавидят признавать, что они чего-либо не знают, соответственно, подавать это следует максимально “небрежным тоном”
Во-вторых, наличие такого знания всегда повышает субъективную оценку справочной системы в целом, т. е. приводит к тому, что пользователи чаще обращаются к справочной системе и от этого эффективнее учатся.
Процедурная справка отвечает на вопрос “Как это сделать?”. В идеале она должна быть максимально доступна, поскольку если пользователь не найдёт нужную информацию быстро, он перестанет искать и так и не научится пользоваться требуемой функцией, а то и программой целиком.
Контекстная справка отвечает на вопросы “Что это делает” (в ПО) и “Зачем это нужно” (для сайтов). Это различные всплывающие “бабблы” и тултипы. Они ни в коем случае не должны прерывать работу пользователя. На сайте это может быть информация, появляющаяся в строке состояния браузера. Такая справка не может быть вынесена из интерфейса, должна быть частью интерфейса. В связи с последним замечанием появляется вопрос: является ли отключаемая строка состояния браузера частью контекстной справки сайта, ведь строка состояния не является элементом интерфейса сайта.
Что касается сообщений об ошибках, то они должны отвечать всего на три вопроса:
В чём заключается проблема?
Как исправить эту проблему сейчас?
Как сделать так, чтобы проблема не повторилась?
При этом отвечать на все эти вопросы следует вежливым и понятным пользователю языком.
Среды передачи справок:
Бумажная книга
Справочная карта
Структурированная электронная документация
Фрагменты пространства интерфейса
Всплывающие подсказки
Бумажная книга поставляется со многими продуктами, и даже не только с ПО. Справочная карта – схема, на которой основные действия показаны в виде рисунков или пиктограмм. Пример – какой провод в какой разъём включается. Электронная документация – название говорит само за себя. Примечательно то, что с последние годы со смартфонами практически не идёт бумажная документация, вся необходимая справка помещается сразу в смартфон. Фрагмент пространства интерфейса и всплывающие подсказки – тут и так всё понятно.
Реализация справок:
Базовая и обзорная справки помещаются в бумажную документацию
Справка предметной области идёт в бумажную документацию, а также использует фрагменты пространства интерфейса
Процедурная справка использует структурированную электронную документацию (например, в Qt мы можем выделить объект, нажать F1 и получить информацию сразу об этом конкретном объекте)
Контекстная справка – ToolTip и бабблы.
Спиральность справочной системы
При возникновении вопроса пользователь получает чрезвычайно сжатый, но ограниченный ответ (3-5 предложений). Если ответ удовлетворяет пользователя, он продолжает работу, и время обращения к справочной системе в этом случае становится минимальным. Если же ответ оказался недостаточным, пользователь может запросить более полный, но более объёмный ответ (допустим, несколько абзацев). Если и этот ответ оказался недостаточным, пользователь может обратиться к ещё более объёмному ответу (несколько страниц). Таким образом, пользователь получает именно тот объём справочной информации, который ему нужен.
Тема следующего занятия – тестирование ПО. У нас осталось всего две лабораторные.
28.04.2012 Подготовка ко второй части второй лабораторной |
ЛАБОРАТОРНАЯ РАБОТА №2. ЧАСТЬ 2.
Вторая часть лабораторной состоит в описании каждого из созданных use-case’ов. Делается это посредством описания бизнес-прецедентов с помощью следующего шаблона: Учебные материалы\Прикладное ПО\Шаблон описания бизнес-прецедента.docx.
Задание: описать все прецеденты, созданные в первой части второй лабораторной.
ПРИКЛАДНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ Слива М. В. |
04.09.2012 Лекция |
4-й курс.
Курс: 6 лекций, 8 лабораторных, контрольная работа.
ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
То, насколько качественно проведено тестирование, зависит многое.
Тестирование – это процесс выполнения программы с целью обнаружения ошибок. Каждый тест определяет:
Свой набор данных и условий для запуска программы
Набор ожидаемых результатов программы.
Хорошим считают тестовый вариант с высокой вероятностью обнаружения ещё не раскрытой ошибки. Иными словами, следует предотвратить как можно больше ситуаций возникновения ошибки ещё до начала тестирования. Цель проектирования тестовых вариантов – систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости. Тестирование требует выработки стратегии.
Тестирование обеспечивает:
Обнаружение ошибок
Демонстрацию соответствия функций программы её назначению
Демонстрацию реализации требований к характеристикам программы
Отображение надёжности как индикатора качества программы
Но тестирование не может показать отсутствие дефектов, оно может показать только присутствие дефектов. Важно помнить это при проведении тестирования.
Информационные потоки процессы тестирования:
Если функции ПО реализованы правильно, и обнаруженные ошибки легко исправляются, то можно сделать два вывода: качество и надёжность ПО удовлетворительны; тесты не способны обнаружить ошибки.
Чем раньше начинается тестирование продукта, тем дешевле оно обходится разработчику.
Два принципа тестирования программы:
Функциональное тестирование (тестирование “чёрного ящика”)
Структурное тестирование (тестирование “белого ящика”)
Тестирование “чёрного ящика”.
Известные: функции программы
Исследуются: работа каждой функции на всей области определения
Основное место приложения тестов “чёрного ящика” – интерфейс ПО.
Эти тесты демонстрируют:
Как выполняются функции программы
Как принимаются исходные данные
Как вырабатываются результаты
Как сохраняется целостность внешней информации
Тестирование “белого ящика”.
Известна: внутренняя структура программы
Исследуются: внутренние элементы программы и связи между ними
Объектом тестирования здесь является не внешнее, а внутренне поведение программы.
Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом. Обычно анализируются управляющие связи элементов, реже – информационные связи.
Методика тестирования программных систем:
Кодирование
Тестирование элементов
Проектирование
Тестирование интеграции
Анализ требований
Тестирование правильности
Системный анализ
Системное тестирование
Виды тестирования:
Тестирование элементов. Цель – индивидуальная проверка каждого модуля. Используются способы тестирования “белого ящика”
Тестирование интеграции. Цель – тестирование сборки модулей в программную систему. В основном применяют способы тестирования “чёрного ящика”
Тестирование правильности. Цель – проверить реализацию в программной системе всех функциональных и поведенческих требований, а также требований эффективности. Используются исключительно способы тестирования “чёрного ящика”
Системное тестирование. Цель – проверка объединения и взаимодействия всех элементов компьютерной системы, реализации всех системных функций.
Когда заканчивать тестирование?
Можно с 95%-ой уверенностью сказать, что проведённое тестирование было достаточным, если вероятность безотказной работы компьютера с программным продуктом в течение 1000 часов составляет по меньшей мере 0,995.
Математическая модель отказов.
Для логарифмической модели Пуассона формула расчёта текущей интенсивности отказов имеет вид:
где:
– это текущая интенсивность программных
отказов (количество отказов на единицу
времени)
– начальная интенсивность отказов (в
начале тестирования)
– экспоненциальное уменьшение
интенсивности отказов за счёт
обнаруживаемых и устраняемых ошибок
– время тестирования
С помощью этой формулы можно предсказать снижение ошибок в ходе тестирования, а также время, требующееся для достижения допустимо низкой интенсивности отказов.
Далее следует поэтапное описание тестирования ПО.
Тестирование элементов
Тестированию подвергаются:
Интерфейс модуля
Внутренние структуры данных
Независимые пути
Пути обработки ошибок
Граничные условия
Интерфейс модуля тестируется для проверки правильности ввода-вывода тестовой информации. Если нет уверенности в правильном вводе-выводе данных, нет смысла проводить другие тесты. Исследование внутренних структур данных гарантирует целостность сохраняемых данных. Тестирование независимых путей гарантирует однократное выполнение всех операторов модуля. При тестировании путей выполнения обнаруживаются следующие категории ошибок: ошибочные вычисления, некорректные сравнения, неправильный поток управления.
Выявляются следующие распространённые ошибки вычислений: неправильный или неполный приоритет арифметических операций, смешанная форма операций, некорректная инициализация, несогласованность в представлении точности, некорректное символическое представление выражений.
Ошибки сравнения и неправильных потоков управления: сравнение различных типов данных, некорректные логические операции и приоритетность, ожидание эквивалентности в условиях, когда ошибки точности делают эквивалентность невозможной, некорректное сравнение переменных, неправильное сокращение цикла, отказ в выходе при отклонении итерации, неправильное изменение переменных циклов.
Тестирование путей обработки ошибок:
Донесение об ошибке невразумительно
Текст донесения не соответствует обнаруженной ошибке
Вмешательство системных средств регистрации аварии произошло до обработки ошибки в модуле
Обработка исключительного условия некорректна (не предпринимается никаких действий по устранению ошибки)
Описание ошибки не позволяет определить её причину
Граничное тестирование производится в случаях:
При обработки n-го элемента n-элементного массива
При выполнении m-й итерации цикла с m проходами
При появлении минимального (максимального значения)
При тестировании элементов используются дополнительные средства тестирования каждого конкретного модуля – это драйвер тестирования и заглушки.
Драйвер тестирования – это управляющая программа, которая принимается исходные данные (InData) и ожидаемые результаты (ExpRes) тестовых вариантов, запускает в работу тестируемый модуль, получает из модуля реальные результаты (OutData) и формирует донесения о тестировании.
Заглушки замещают модули, которые вызываются тестируемым модулем.
Заглушка, или “фиктивная подпрограмма”, реализует интерфейс подчинённого модуля, может выполнять минимальную обработку данных, имитирует приём и возврат данных.
<вставляем сюда рисунок>
Тестирование интеграции
Проводится при сборке цельной программной системы. Тесты проводятся для обнаружения ошибок интерфейса. Категории ошибок интерфейса:
Потеря данных при прохождении через интерфейс
Отсутствие в модуле необходимой ссылки
Неблагоприятное влияние одного модуля на другой
Подфункции при объединении не образуют требуемую главную функцию
Отдельные (допустимые) неточности при интеграции выходят за допустимый уровень
Проблемы при работы с глобальными структурами данных
Возможны два варианта тестирования интеграции.