1. Принципы разработки

Интерфейс – это набор стандартных приемов взаимодействия с тех­ни­кой. Рассмотрим основные принципы его разработки.

1. Отдельная разработка интерфейса. При разработке различ­ных час­тей интерфейса могут привлекаться специалисты различных спе­циаль­ностей, например: художники, дизайнеры, психологи, медики, поль­зова­тели, прог­рам­мисты.

2. Учет возможностей аппаратных и программных средств разработчика и пользователя.

3. Стандартизация, унификация и последовательность разработки. Исполь­зование общепринятых методов, приемов для всех элементов ПС. Необхо­ди­мо применять стан­дарты ISO, IEC, NIST, IEEE, ГОСТ, Windows, Office и др.

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

5. Привлечение пользователя к разработке интерфейса. Ис­поль­­зование знаний пользователя в предметной области, согласование прини­маемых решений.

6. Следует предусмотреть средства адаптации к пользователю. Адаптация – это способность устанавливать соответствие с уровнем подготовки пользователя. Существуют три типа адаптации:

косметическая – использование клавиш прямого вызова; исключе­ние повторных запросов; использование синонимов, опережающих отве­тов, умолчаний, использование макросов; многоуровневая помощь;

фиксированная – пользователь явно выбирает уровень диалоговой поддержки;

автоматическая – система строит модель поведения пользователя, изме­няясь в процессе работы с пользователем, распознавая его харак­те­ристики (время ответа, ошибки, обращение к помощи).

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

7. Гибкость при анализе ответов пользователя. После сравнения полученного и проверочного ответов выра­ба­ты­вается признак: ответ правильный или нет. Допускается гибкость при сравнении, если при неточном совпадении ответа с эталоном при некоторых условиях выра­ба­тывается признак правильности. Способы достижения гибкости: сравнение со списком вариантов ответов, совпадение сокращений, частичное совпадение, алго­ритм сокращения слов, использование синонимов.

8. Интеллектуализация интерфейсов. Достижима путем преобра­зо­­ва­ния вход­ных сообщений в соответствии с контекстом отображаемой пред­мет­ной об­ласти. Основ­ными средствами интерфейса являются голосовой ввод инфор­­мации и способность распознавания образов для интерпретации вход­ных сообщений; использование экспертных систем.

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

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

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

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

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

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

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

Адаптация - это способность устанавливать соответствие с уровнем подготовки пользователя. Существуют три типа адаптации:

косметическая - использование команд-акселераторов, исключе­ние повторных запросов, использование синонимов, опережающих отве­тов, умолчания, использование макросов, многоуровневая помощь;

фиксированная - пользователь явно выбирает уровень диалоговой поддержки;

автоматическая - система строит модель поведения пользователя, изме­няясь по мере работы с пользователем, распознавая его характеристики (время ответа, ошибки, обращение к помощи).

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

Способы достижения гибкости: сравнение со списком возможных сообщений; совпадение сокращений; частичное совпадение; алгоритм сокращения слов; использование синонимов.

Интеллектуальные интерфейсы преобразуют входные сообщения в соответствии с контекстом отображаемой предметной области. Основ­ными средствами интерфейса являются голосовой ввод инфор­мации; способность распознавания образов для интерпретации входных сообщений.

6. Организация и планирование процессов разработки программных средств. Формы организации разработки, виды планов и формы их записи.

Планирование разработки

Базой эффективного управления проектом является план, в котором задачи исполнителей частных работ согласованы с выде­ляемыми для них ресурсами, а также между собой по результа­там и срокам их достижения. План проекта отражает рациональ­ное сочетание целей, стратегий действий, конкретных процедур, доступных ресурсов и других компонент, необходимых для дости­жения поставленной основной цели с заданным качеством. Пла­нирование проектов должно обеспечивать компромисс между характеристиками создаваемой системы и ресурсами, необходимыми на ее разработку и применение. Исходные данные для планирования бывают двух типов: характеристика самого пла­ни­ру­емого ПС и характеристика прототипов ПС. Сов­мест­ная корректная обработка исходных данных поз­во­ля­ет получать новые, прогнозируемые характери­стики процессов создания ПС.

Исходные данные ПС отражают характеристики кон­кретного объ­екта, доступные методы и средства автоматизации труда при его создании. Эти данные последовательно детализи­руются и уточняются в процессе проектирования ПС. Проектируемые ПС характеризуются основ­ными показателями: класс ПС, его объем, связь с реальным масштабом времени и степень ис­пользования готовых апробированных компонент, финан­со­вые, кадровые и аппа­ратурные ограничения и др.

Исходные данные прототипов ПС для планирования разработки ПС составляют обобщенный опыт и характеристики прототипов ПС. Для достоверного планирования и прогнозирования необходи­мы накопление, изучение и обобщение конкретных данных о за­вершенных разработках ПС в различных аспектах. Эти данные, получаемые путем анализа завер­шен­ных предше­ствующих разработок, целесообразно разделить на две группы:

1) технико-эко­но­мические показатели, отражающие трудоемкость, длительность, число специалистов и другие, наиболее общие эко­номи­чес­кие характеристики процесса разработки ПС;

2) сведения о реализованных планах разработки ПС.

На основе исходных данных о текущем проекте ПС и его прототипах с учетом их последовательной детализации осуществляется планирование разработки, которое базируется на:

• последовательной, иерархической детализации и уточнении планов в соответствии с повышением достоверности и полноты исходных данных, получаемых в процессе разработки ПС;

• автоматизированном выборе варианта первичного перечня работ, адекватного исходным данным проектируемого ПС, и возможности его уточнения пользователем;

• унификации и преемственности форм исходных, данных и отчетных доку­ментов с постепенным расширением их номенклатуры и углублением содержания;

• ведения диалога пользователя со средством автоматизации пла­ни­рования на базе системы меню, мнемонических, графических схем и многооконной детализации результатов анализа;

• на возможности регистрации и хранения прогнозов и рабочих планов проведения работ для их использования при управлении проектом и при планировании аналогичных разработок.

Обычно выделяют следующие стадии планиро­вания:

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

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

• подготовка оперативного плана (обычно на месяц) и управление реализацией плана, его оперативная корректиров­ка и перераспределение ресурсов в соответствии с особенностями текущего состояния проекта;

• обобщение результатов планирования и управления проектом для использования этих данных в качестве прототипа при разра­ботке последующих проектов.

7. Методы определения трудоемкости и стоимости разработки программных средств.

Оценка стоимости разработки

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

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

При использовании нормативного метода необходимо разработать нормы затрат на различные виды работ (например, на проектирование, программирование и др.). Для примера таких норм и методики их использования можно привести документ «Типовые нормы времени на программирование задач для ЭВМ», который разработан Всесоюзным научно-исследовательским институтом статистической информационной системы Госкомстата СССР (ВНИПИ Статинформ Госкомстата СССР) под методическим руководством Центрального бюро нормативов по труду Госкомтруда СССР и введен в действие Постановлением Государственного комитета СССР по труду и социальным вопросам и Секретариата ВЦСПС от 27 июля 1987г. № 454/22-70. Сущность нормирования, изложенная в этом документе, заключается в следующем. Все задачи делятся на классы (подсистемы АИС), например, оперативного управления, финансовые и бухгалтерские, технико-экономического планирования, управления кадрами и др. Для каждого класса задач предложена таблица: в заголовке колонок указываются число разновидностей выходных документов, в заголовке строк (первая колонке таблицы) – число разновидностей входных документов, а в ячейках таблицы – нормативное количество дней, необходимых для программирования задач с соответствующим числом разновидностей входных и выходных документов, указанных в заголовках строк и колонок соответственно. Дополнительно вводятся три весовых поправочных коэффициента, которые учитывают:

- новизну задачи (оригинальные, оригинальные с типовыми элементами, типовые с элементами оригинальности, типовые);

- сложность входных и выходных документов (например, в документе несколько таблиц и разделов);

- уровень автоматизации программирования используемого языка программирования.

Норматив умножается на значения этих коэффициентов и формируется итоговый норматив на программирование задачи.

Для оценки других видов работ (проектирование, вверение, разработка технического задания и др.) предложены соответствующие формулы перевода норм программирования в нормы для этих работ. Таким образом, можно рассчитать трудоемкость разработки по всем видам работ и в целом по всей задаче, а если указать стоимость одного рабочего дня, то можно рассчитать калькуляцию по всем видам работ в стоимостном выражении. Эти нормативы можно использовать и в настоящее время после их корректировки с учётом использования современных средств разработки АИС.

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

8. Стандарты жизненного цикла программных средств: ISO/IEC 12207 (основные, вспомогательные и организационные процессы), ГОСТ 19.102-77 (основные стадии и этапы). Назначение, сравнительный анализ.