Методические указания по выполнению лабораторных и практических работ по мдк
 Скачать 3.25 Mb.
|
|
Практическая работа № 1.35. Разработка технического задания Цель работы: изучение руководящих документов по составлению технического задания. Разработка проекта технического задания на программное обеспечение. Теоретический материал Общие сведения Техническое задание (ТЗ, техзадание) - основной документ, содержащий требования заказчика к системе, в соответствии с которыми осуществляется создание и разработка конечного продукта. Техническое задание на программу и программное обеспечение разрабатывается в соответствии с требованиями следующих документов: - ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению; - ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Основанием для разработки ТЗ чаще всего является договор. Техническое задание позволяет: - исполнителю - понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы; - заказчику - осознать, что именно ему нужно; - обеим сторонам - представить готовый продукт; - исполнителю - спланировать выполнение проекта и работать по намеченному плану; - заказчику - требовать от исполнителя соответствия продукта всем условиям, оговоренным в ТЗ; - исполнителю - отказаться от выполнения работ, не указанных в ТЗ; 146 - заказчику и исполнителю - выполнить полную попунктную проверку готового продукта; - избежать ошибок, связанных с изменением требований (на всех стадиях и этапах создания, за исключением испытаний). Если поставлены сжатые сроки подготовки ТЗ и заказчик не требует оформления документации в соответствии с государственным стандартом, то можно использовать шаблон технического задания по стандарту IEEE Std 830, который предполагает, что детальные требования могут быть обширными и не существует оптимальной структуры для всех систем. По этой причине стандартом рекомендуется обеспечивать такое структурирование детальных требований, которое делает их оптимальными для понимания. Стандартом рекомендуются различные способы структурирования детальных требований для различных классов систем. Существует и третья альтернатива для выбора шаблона технического задания, когда заказчик предлагает использовать принятый в компании корпоративный шаблон для описания требований к информационным системам. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания. ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению Данный стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Согласно стандарту техническое задание должно содержать следующие разделы: - введение; - основания для разработки; - назначение разработки; - требования к программе или программному изделию; - требования к программной документации; - технико-экономические показатели; - стадии и этапы разработки; - порядок контроля и приемки; - в техническое задание допускается включать приложения. В зависимости от особенностей программы или программного изделия, допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие. В разделе «Основания для разработки» должны быть указаны: - документ (документы), на основании которых ведется разработка; - организация, утвердившая этот документ, и дата его утверждения; - наименование и (или) условное обозначение темы разработки. Применительно к специфике учебного процесса основанием может служить задание на курсовое проектирование, приказ по институту от . . за №., договор . . за N., и т.п. Наименование: «Разработка лабораторной работы № 1». Шифр: «ЛАБА-001». В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы: - требования к функциональным характеристикам; - требования к надежности; 147 - условия эксплуатации; - требования к составу и параметрам технических средств; - требования к информационной и программной совместимости; - требования к маркировке и упаковке; - требования к транспортированию и хранению; - специальные требования. 1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п. Например: Программа должна позволять ... вычислять ... строить... создавать ... Исходные данные: текстовый файл с заданной ... Входные и выходные данные : графическая и текстовая информация - результаты анализа системы.; текстовые файлы - отчеты о ... диагностика состояния системы и сообщения о всех возникших ошибках. 2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.). Для программного обеспечения надежность зависит не столько от исполнителя, сколько от надежности технических средств и операционной системы, поэтому в разделе обязательно следует написать такую фразу: «Требования к обеспечению надежного (устойчивого) функцио- нирования программы не предъявляются» Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать нескольких минут при условии соблюдения условий эксплуатации тех- нических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств. Перечень аварийных ситуаций также составляет заказчик и согласовывает с исполнителем, т.е. это время на перезагрузку операционной системы, если отказ не фатален и не вызван крахом операционной системы или выходом из строя технических средств. Отказы программы возможны вследствие некорректных действий оператора (пользователя) при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу пользователя без предоставления ему административных привилегий. 3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала. Здесь можно ограничиться следующими фразами: «Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК», «Программа должная быть рассчитана на непрофессионального пользователя» и т.п. 4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик. Как правило, тут указывают минимальные требования к технике, на которой будет функционировать разработанное программное обеспечение. Например, IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя: - процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее; - оперативную память объемом, Гб - 2, не менее; - и так далее. 5. В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой. При необходимости должна обеспечиваться защита информации и программ. 148 Например: Программа должна работать автономно под управлением ОС MS Windows версии не ниже 7. Базовый язык программирования — C++. 6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки. Например, программное изделие должно иметь маркировку с обозначением товарного знака компании-разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера сертификата соответствия Госстандарта России (если таковой имеется). Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74. Упаковка программного изделия должна осуществляться в упаковочную тару предприятия-изготовителя (поставщика). Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от +15 до +40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде. 7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях. Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный. При транспортировании и хранении программного изделия должна быть предусмотрена защита от попадания пыли и атмосферных осадков. Не допускается кантование программного изделия. Климатические условия транспортирования приведены ниже: - температура окружающего воздуха, °С - от ... до ...; - атмосферное давление, кПа - ..; - относительная влажность воздуха при 25 °С - ... . В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней. В состав программной документации должны входить: - техническое задание; - программа и методика испытаний; - руководство системного программиста; - руководство оператора; - ведомость эксплуатационных документов. Программа и методика испытаний потребуется, чтобы показать заказчику, что разработанная исполнителем программа соответствует требованиям согласованного и утвержденного технического задания. После проведения совместных (приемо-сдаточных) испытаний заказчик и исполнитель подпишут акт завершения работы. Таким образом, работа будет закрыта, условия договора выполнены. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии и сроки разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, определяют исполнителей. Главное - грамотно определиться со сроками. По возможности, старайтесь равномерно распределить этапы по срокам (и суммам). Помните, что не все проекты доживают до последней стадии. А отчеты должны быть по каждому этапу. Помните также, что больше всего времени займет рабочий проект. Если вы не успеете сделать в срок документацию, то Заказчик имеет полное право вообще не принять работу со всеми вытекающими последствиями. Основными и непременными стадиями и этапами являются само техническое задание, эскизный проект, технический и рабочий проекты. 149 Эскизный проект. На этой стадии детально разрабатываются структуры входных и выходных данных, определяется форма их представления. Разрабатываются общее описание алгоритма, сам алгоритм, структура программы, план мероприятий по разработке и внедрению программы. Технический проект. Содержит разработанный алгоритм решения задачи, а также методы контроля исходной информации. Здесь же разрабатываются средства обработки ошибок и выдачи диагностических сообщений, определяются формы представления исходных данных и конфигурация технических средств. Рабочий проект. На этой стадии осуществляются программирование и отладка программы, разработка программных документов, программы и методики испытаний. Подготавливаются контрольно-отладочные примеры. Окончательно оформляются документация и графический материал. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы. Например, контроль и приемка разработки осуществляются на основе испытаний контрольно-отладочных примеров. При этом проверяется выполнение всех функций программы. В приложениях к техническому заданию при необходимости приводят: - перечень научно-исследовательских и других работ, обосновывающих разработку; - схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке; - другие источники разработки. Задание на лабораторную работу Разработать проект технического задания на программное обеспечение в соответствии с ГОСТ 19.201-78. Программное обеспечение должно включать в свой состав: - серверную часть; - клиента, функционирующего на ПЭВМ; - мобильного клиента, функционирующего на смартфоне; - веб-клиента, функционирующего в браузере. По желанию состав программного обеспечения может быть расширен. Требования к функциональным характеристикам необходимо указать для каждого клиента. Вопросы для самопроверки 1. Зачем разрабатывают ТЗ? 2. Какими стандартами регулируется содержимое технического задания? 3. Какие существуют стадии и этапы разработки? 150 4. Раскройте понятие «время восстановления после отказа». 5. Что должен содержать подраздел «Требования к функциональным характеристикам» раздела «Требования к программе или программному изделию»? 6. Обязательно ли присваивать условное обозначение темы разработки? Практическая работа № 36. Разработка интерфейса пользователя. Практическая работа № 1.37. Проектирование пользовательского интерфейса десктопного приложения . Практическая работа № 1.38. Проектирование пользовательского интерфейса десктопного приложения Цель работы: изучение принципов проектирования пользовательского интерфейса. Разработка пользовательского интерфейса десктопного приложения. Теоретический материал Общие сведения о десктопных приложениях Десктопные приложения - это программы, требующие наличия оператора (человека, работающего с программой), содержащие в себе всю полную функциональность и способные работать отдельно на любой машине изолированно от других приложений. Microsoft Word, Excel, Блокнот, однопользовательские игры - все это примеры десктопных приложений. Для их работы необходимы лишь достаточные аппаратные ресурсы компьютера, само приложение и набор библиотек, содержащих функции для работы с приложением. Десктопные приложения могут быть также и многопользовательскими. Например, редактор файлов, который в зависимости от логина и пароля, введенных при запуске, будет давать доступ к различным файлам. И программа, и файлы находятся на одном компьютере, просто производится локальное разграничение доступа для разных пользователей. Пользовательский интерфейс Пользовательский интерфейс (UI) - это способ, которым вы выполняете какую-либо задачу с помощью какого-либо продукта, т.е. совершаемые вами действия и то, что вы получаете в ответ. Программный интерфейс не только решает нашу проблему взаимодействия с приложением, но и делает это взаимодействие максимально комфортным. Нам важно наличие интерфейса, позволяющего при меньшем количестве усилий ознакомиться с возможностями приложения и понять принципы работы в нем. Чтобы не возникло проблем при использовании какого-либо приложения, можно визуализировать его функциональные возможности в виде понятных элементов, и за этой визуализацией кроется целая кухня UX/UI-дизайна. Грань между UX (User Experience) и UI (User Interface) очень тонка, но если разобраться, то становится ясно, что UX помогает понять пользователя. В UX-дизайне больше психологического аспекта, нежели технологического. UX изучает пользователя: как пользователь живет, что он думает, как и что делает, что его окружает. Перед дизайнером ставится задача - помочь обычному человеку легко разобраться с вашим программным продуктом и получить при этом удовлетворение от работы с ним. А понять пользователя очень важно. Никому не захочется заполнить двадцать полей формы для регистрации на сайте или перещелкать штук пятнадцать вкладок, прежде чем добраться до нужной функции. «Пользователя не следует заставлять взаимодействовать с программой дольше, чем абсолютно необходимо для решения той или иной задачи» (из книги Алана Купера «Психбольница в руках пациентов»). Этапы разработки пользовательского интерфейса Полный цикл разработки интерфейса представлен на рис. 2.1. 151 Рис. 2.1. Этапы разработки пользовательского интерфейса Для сокращения общего времени разработки определение стилистики начинается после пользовательских сценариев. Исследование. На этапе исследования проводится сбор информации о продукте, клиенте, его конкурентах или близких аналогах, сбор статистики использования текущего интерфейса (например, сайта или мобильного приложения), анализ устройств предполагаемой целевой аудитории. Если уже известно, кто будет воплощать интерфейс в жизнь (разработчики), то знакомимся с ними и выясняем их возможности и ограничения. Этот этап помогает понять, для кого разрабатывается интерфейс, с какими ограничениями следует его делать (размеры экранов, интерактивность), как не стоит делать (например, быть непохожими на конкурентов). Пользовательские сценарии. На основе предоставленного описания работы интерфейса создается список задач (пользовательских сценариев), которые может выполнять пользователь в рамках интерфейса. Например, обновить аватарку в профиле. Все задачи расписываются по шагам, которые необходимо предпринять для решения задачи. Например: - зайти на сайт; - авторизоваться; - перейти в профиль; - нажать на аватарку; - выбрать файл; - подтвердить или изменить кадрирование изображения; - сохранить. Составленные списки шагов для каждой задачи помогают понять, где путь для решения слишком долог относительно остальных задач. Этап пользовательских сценариев больше всего подходит для сокращения пути решения задач пользователей в рамках интерфейса. Пример выше можно сократить на несколько шагов. Например, сделать сохранение автоматическим, а обрезание изображения - опциональным. Структура интерфейса. Полученный список шагов на предыдущем этапе ложится в основу структуры интерфейса. Становится известно количество экранов, их краткое содержание и положение в общей структуре. На данном этапе строится карта экранов ( |