Требования предъявляемые к программе

ТС ПО в общем случае можно описать следующей системой понятий:

Технология создания ПО — упорядоченная совокупность взаимосвязанных технологических процессов в рамках ЖЦ ПО.

Технологический процесс — совокупность взаимосвязанных технологических операций.

Технологическая операция — основная единица работы, выполняемая определенной ролью, которая:

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

Рабочий продукт — информационная или материальная сущность, которая создается, модифицируется или используется в некоторой технологической операции (модель, документ, код, тест и т.п.). Рабочий продукт определяет область ответственности роли и является объектом управления конфигурацией.

Требования, предъявляемые к педагогическим работникам

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

Руководство — практическое руководство по выполнению одной или совокупности технологических операций. Руководства включают методические материалы, инструкции, нормативы, стандарты и критерии оценки качества рабочих продуктов.

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

Основным требованием, предъявляемым к современным ТС ПО, является их соответствие стандартам и нормативным документам , связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Согласно этим нормативам, ТС ПО должна поддерживать следующие процессы:

• управление требованиями;
• анализ и проектирование ПО;
• разработка ПО;
• эксплуатация;
• сопровождение;
• документирование;
• управление конфигурацией и изменениями;
• тестирование;
• управление проектом.

Полнота поддержки процессов ЖЦ ПО должна поддерживаться комплексом инструментальных средств (CASE-средств).

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

Требования к рабочей учебной программе по предмету «Технология», предъявляемые при контроле деятельн

Другим важным требованием является адаптируемость к условиям применения , которая достигается за счет поставки технологии в электронном виде вместе с CASE-средствами и библиотеками процессов, шаблонов, методов, моделей и других компонентов, предназначенных для построения ПО того класса систем, на который ориентирована технология. Электронные технологии должны включать средства, обеспечивающие их адаптацию и развитие по результатам выполнения конкретных проектов. Процесс адаптации заключается в удалении ненужных процессов и действий ЖЦ ПО, в изменении неподходящих или в добавлении собственных процессов и действий, а также методик, стандартов и руководств.

Внедрение ТС ПО в организации

При внедрении ТС ПО следует руководствоваться рекомендациями, приведенными в стандартах [27], [28], [29] (их краткий перевод приведен в [4]). Эти рекомендации достаточно актуальны и ценны, поскольку отражают опыт, накопленный многими зарубежными пользователями и разработчиками ТС ПО в течение длительного периода их существования.

Термин «внедрение» используется в широком смысле и включает все действия — от оценки первоначальных потребностей до полномасштабного использования ТС ПО в различных подразделениях организации. Процесс внедрения ТС ПО состоит из следующих этапов:

1. Определение потребностей в ТС ПО, характеристик объекта внедрения и проектов создания ПО.
2. Определение требований, предъявляемых к ТС ПО (анализ характеристик объекта внедрения и проектов, обоснование требований к ТС ПО, определение приоритетов требований).
3. Оценка вариантов ТС ПО. Предварительная экспертная оценка заключается в анализе доступных ТС ПО на предмет соответствия требованиям, неудовлетворительные варианты (с точки зрения реализации наиболее приоритетных требований) отвергаются, формируется список претендентов. При детализированной оценке для каждой ТС ПО-претендента формируется ее детальное описание. Источники информации для описания — техническая документация поставщика, доступные данные о реальных внедрениях, результаты выполнения пилотных проектов.
4. Выбор ТС ПО. Производится сравнительный анализ технологий и окончательный выбор ТС ПО с помощью экспертной оценки.
5. Адаптация ТС ПО к условиям применения. Производится формирование конкретной рабочей конфигурации ТС ПО, адаптированной к условиям объекта внедрения.

В процессе внедрения ТС ПО собирается статистика и оценивается эффективность ее внедрения с точки зрения ряда критериев (минимум трудоемкости сопровождения ПО, минимум затрат на сопровождение ПО и др.). При изменении условий объекта внедрения и по результатам анализа эффективности внедрения ТС ПО принимается решение: а) о внесении изменений в рабочую конфигурацию ТС ПО; б) о переходе на новую ТС ПО. В случае перехода повторяются пп. 3)-4)-5).

Оценка и выбор ТС ПО

Цель процесса оценки — определение функциональности и качества ТС ПО для последующего выбора. Оценка выполняется в соответствии с конкретными критериями, ее результаты включают как объективные, так и субъективные данные по каждой ТС ПО.

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

Процесс выбора включает в себя следующие действия:

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

Типичный процесс оценки и/или выбора может использовать набор критериев различных типов. Каждый критерий должен быть выбран и адаптирован экспертом с учетом особенностей конкретного процесса.

Исходные данные для оценки и выбора — набор параметров (технико-экономических характеристик) ТС ПО:

1. Функциональные характеристики, ориентированные на процессы жизненного цикла ПО (управление проектом, управление требованиями, управление конфигурацией и изменениями, анализ и проектирование ПО и др.).
2. Функциональные характеристики применения (среда функционирования, совместимость с другими ТС ПО, соответствие технологическим стандартам).
3. Характеристики качества (надежность, удобство использования, эффективность, сопровождаемость, переносимость).
4. Общие характеристики (затраты на технологию, лицензионная политика, оценочный эффект от внедрения ТС ПО, инфрастуктура, требуемая для внедрения ТС ПО, доступность и качество обучения, сертификация поставщика, поддержка поставщика).

На основе данного набора параметров анализируются и классифицируются существующие ТС ПО. Общий набор критериев, применяемых для оценки ТС ПО, приведен в Таб. 1.

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

Минимум трудоемкости создания ПО

Количество человеко-месяцев, затрачиваемых на создание ПО с использованием ТС ПО

Объем работы (измеряемый в количестве строк кода или функциональных точек), приходящийся на единицу трудоемкости (человеко-месяц) при использовании данной ТС ПО

Максимум качества создаваемого ПО

Количество дефектов в рабочих продуктах при использовании данной ТС ПО

(Доход от использования ПО — Затраты на создание и сопровождение ПО) / (Затраты на создание и сопровождение ПО)

Минимум затрат на сопровождение ПО

Отношение стоимости сопровождения ПО при использовании данной ТС ПО к совокупным затратам на информационные ТС ПО в организации

Минимум времени внедрения ТС ПО

Временной интервал от начала внедрения ТС ПО до выхода на безубыточный уровень (начало возврата инвестиций в ТС ПО)

Минимум затрат на внедрение ТС ПО

Суммарная стоимость приобретения, обучения и сопровождения ТС ПО

Минимальный срок окупаемости затрат на внедрение ТС ПО

Временной интервал от начала внедрения ТС ПО до полной окупаемости затрат на ее внедрение

Выполнение пилотного проекта

Перед полномасштабным внедрением выбранной ТС ПО в организации выполняется пилотный проект, целью которого является экспериментальная проверка правильности решений, принятых на предыдущих этапах, и подготовка к внедрению.

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

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

Пилотный проект должен обладать следующими характеристиками:

• Типичность предметной области. Чтобы облегчить окончательное определение области применения ТС ПО, предметная область пилотного проекта должна быть типичной для обычной деятельности организации. Пилотный проект должен помочь определить любую дополнительную технологию, обучение или поддержку, которые необходимы для перехода от пилотного проекта к широкомасштабному использованию ТС ПО. В рамках этих ограничений пилотный проект должен иметь небольшой, но значимый размер.
• Масштабируемость. Результаты, полученные в пилотном проекте, должны показать масштабируемость ТС ПО. Цель — получить четкое представление о масштабах проектов, для которых данная ТС ПО применима.
• Представительность. Пилотный проект не должен быть необычным или уникальным для организации. ТС ПО должна использоваться для решения задач, относящихся к предметной области, хорошо понимаемой всей организацией.
• Критичность. Пилотный проект должен иметь существенную значимость, чтобы оказаться в центре внимания, но не должен быть критичным для успешной деятельности организации в целом.
• Авторитетность. Группа специалистов, участвующих в проекте, должна обладать высоким авторитетом, при этом результаты проекта будут всерьез восприняты остальными сотрудниками организации.
• Готовность проектной группы. Проектная группа должна обладать готовностью к нововведениям, технической зрелостью и приемлемым уровнем опыта и знаний в данной ТС ПО и предметной области. С другой стороны, группа должна отражать в миниатюре характеристики организации в целом.

В процессе оценки пилотного проекта организация должна определить свою позицию по следующим трем вопросам:

• Целесообразно ли внедрять ТС ПО?
• Какие конкретные особенности пилотного проекта привели к его успеху (или неудаче)?
• Какие проекты или подразделения в организации могли бы получить выгоду от использования ТС ПО?

Возможным решением должно быть одно из следующих:

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

Практическое внедрение ТС ПО

Процесс перехода к практическому использованию ТС ПО начинается с разработки и последующей реализации плана перехода. Этот план может отражать поэтапный подход к переходу — от тщательно выбранного пилотного проекта до проектов с существенно возросшим разнообразием характеристик.

План перехода должен охватывать:

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

План перехода должен определять начальную практику применения и процедуры использования средств. Реальное применение любой ТС ПО в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта (это особенно актуально при коллективной разработке ПО большим количеством групп специалистов). К таким стандартам относятся следующие:

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

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

Результатом данного этапа является внедрение ТС ПО в повседневную практику организации. Кроме того, поддержка ТС ПО включается в план текущей поддержки ПО в данной организации.

Источник: citforum.ru

Основные требования, предъявляемые к разрабатываемым программам

РЕАЛИЗАЦИЯ УПРАВЛЕНИЯ ПРОЦЕССАМИ И РЕСУРСАМИ МНОГОПРОГРАММНЫХ ОПЕРАЦИОННЫХ СИСТЕМ НА УРОВНЕ ДИСПЕТЧЕРИЗАЦИИ: Методические указания по выполнению лабораторного практикума при изучении дисциплины «Системы программирования и алгоритмизация вычислений.» /Ин-т электроники и математики. Сост. П.И.Витушкин. М. 1993г. Стр.44./

Ил. 6 Библиогр.: 24 назв.

Рецензент: профессор, доктор техн. наук – И.В.Солодовников.

СОДЕРЖАНИЕ

1. Введение и структура лабораторного практикума. 4

2. Основные требования, предъявляемые к разрабатываемым программам. 5

3. Краткие сведения о проблемной области выполняемых работ. 5

4. Задания для лабораторных работ. 14

4.1 Лабораторная работа № 1. ”Программная реализация средств представления и управления процессами в многопрограммных ОС”. 14

4.1.1. Формирование дескрипторов процессов. 14

4.1.2. Определение состояний «поступивших» процессов. 15

4.1.3. Формирование и ведение списков дескрипторов процессов. 15

4.1.4. Принцип имитации развития процессов. 16

4.1.5. Организация взаимодействия с «системой». 17

4.1.5.1. Описание состава и назначения команд пользователя «Система» должна выполнять следующие команды пользователя: 17

4.1.5.2. Основные требования к форме ввода команд «системы». 19

4.1.6. Порядок выполнения л.р. № 1. 21

4.1.7. Требования к отчету по л.р. № 1. 21

4.1.8. Контрольные вопросы к л.р. № 1. 22

4.2. Лабораторная работа № 2. «Изучение дисциплин диспетчеризации процессов в многопрограммных ОС». 23

4.2.1. Краткое описание схемы одноочередной круговой (циклической) диспетчеризации. 23

4.2.2. Краткое описание алгоритма многоочередной диспетчеризации для операции Истечение_кванта. 25

4.2.3. Имитация развития процессов при выполнении л. р. № 2. 26

4.2.4. Порядок выполнения л.р. № 2. 27

4.2.5. Требования к отчету по л.р. № 2. 27

4.2.6. Контрольные вопросы к л.р. № 2. 28

4.3. Лабораторная работа № 3. «Реализация дисциплин диспетчеризации процессов с учетом приоритетов». 29

4.3.1. Краткое описание схемы многоочередной диспетчеризации с учетом приоритета. 29

4.3.2. Порядок выполнения л.р. № 3. 32

4.3.3. Требования к отчету по л.р. № 3. 32

4.3.4. Контрольные вопросы к л.р. № 3. 32

4.4. Лабораторная работа № 4. «Реализация дисциплины диспетчеризации процессов с учетом запросов ввода/вывода». 33

4.4.1. Краткое описание схемы диспетчеризации процессов с учетом ввода/вывода и ее реализации. 33

4.4.2. Порядок выполнения и требования к отчету л.р. № 4. 35

4.4.3. Контрольные вопросы к л.р. № 4. 36

1. Введение и структура лабораторного практикума

В третьем семестре изучения дисциплины «Системы программиро­вания и алгоритмизация вычислений» учебным планом специальности 22.03 предусматривается проведение лабораторного практикума в объеме 36 часов.

Лабораторный практикум «Реализация управления процессами и ресурсами многопрограммных операционных систем на уровне диспетчеризации» состоит из следующих четырех лабораторных работ:

1. «Программная реализация средств представления и управле­ния процессами в многопрограммных ОС».

2. «Изучение дисциплин диспетчеризации процессов в многопрограммных ОС».

3. «Реализация дисциплины диспетчеризации процессов с учетом приоритетов».

4. «Реализация дисциплины диспетчеризации процессов с учетом запросов ввода/вывода».

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

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

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

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

B ходе последующих лабораторных работ проводится разработка и программная реализация компонентов модели «операционной системы» развивающая некоторые возможности данной модели.

Схематично, связь лабораторных работ выглядит следующим образом:

Рис.1. Последовательность выполнения лабораторного практикума.

Краткие теоретические сведения об изучаемой проблемной области содержатся в разделе 3.

Задания на выполнение лабораторных работ формулируются и объясняются в разделе 4.

Лабораторный практикум выполняется каждым студентом индивидуально.

Основные требования, предъявляемые к разрабатываемым программам

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

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

2) вводимые команды и информация, выводимая на экран, должны дублироваться в файле протокола работы с программой, распечатка которого входит в состав отчета;

3) структура программы должна быть построена по модульному принципу и должна допускать модификацию программы.

Источник: megaobuchalka.ru

Глава 6. Основные требования, предъявляемые к программному продукту со стороны пользователя

Важнейшим критерием оценки программной системы является ее доступность для пользователя. Приобретая продукт, покупатель оценивает затраты на его освоение и возможные трудности при эксплуатации.

Покупатель оценивает стоимость программной системы и трудоемкость ее освоения (Т):

где к – стоимость норма-часа специалиста, который осваивает программный продукт.

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

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

1) Текст – процессоры имеют в своем составе команду GLOBAL FORMAT, с помощью которой форматируют текст. При ее применении текст форматируется со вставленными в него таблицами. Таблицы, после применения такой команды превращаются в нечто, что не читается и практически не восстанавливается;

2) электронные таблицы (Spread Sheets): LOTOS 1-2-3, SUPERCALC, QUATTRO PRO, EXCEL, которые предоставляют программисту самые широкие возможности при создании продукта, которые передаются пользователю. Пользователь вынужден работать со всем инструментарием, который предоставляется и программисту. И это богатство возможностей часто играет с неквалифицированным пользователем скверную шутку. Например, при использовании команд типа: SORT или ARRANGE работа пользователя будет безнадежно испорчена. При этом, подобные команды выполняются электронной таблицей без лишних расспросов, к тому же, команда ARRANGE в меню стоит первой.

Недопустимо, чтобы продукт, явно ориентированный на пользователя, предъявлял к нему такие требования, которые затруднят и многих программистов. А также очень нежелательно, чтобы пользователю надо было бы освоить большое число команд (например, в редакторе их “всего” от 44 до 300 и более). В электронных таблицах, например, используется восьмиуровневое иерархическое меню, каждый уровень содержит до 20 команд, а общее их сочетание достигает 15 тыс.. Что делать пользователю (а также и программисту), если изрядная часть этих 15 тыс. команд приводит к фатальным последствиям?

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

Допустимость для пользователя программного продукта заключается в том, чтобы продукт НЕ потребовал от него.

1) высокого интеллекта;

2) тренированной памяти;

3) интеллектуальных усилий;

4) полного самоконтроля;

5) напряженного внимания;

6) трудолюбия и полной самоотдачи;

7) интенсивной работы с клавиатурой или мышью.

Идея с позиций доступности – это вирусы и игровые программы, которые имеют широкое и долговременное распространение. Их отличают простота, так как для конфигурирования и управления используется обычно весьма ограниченный набор клавиш (чаще всего “стрелки“ (ARROWS) и ENTER, либо SPACE).Расположение командных клавиш таково, что и забывчивый и неловкий пользователь не испытывает затруднений и редко промахивается, причем даже промах не приводит к фатальным последствиям. Прочие клавишные команды (если они есть) не являются обязательными.

Программный продукт должен требовать от пользователя только умения читать и писать (не считая, конечно, знаний в проблемной области). Примером такого подхода является программный продукт фирмы GreenSoft, который получил название HAMMER-продукт. Программный продукт должен быть таковым, чтобы, если пользователь впервые увидел компьютер, то на результате его работы с программой это никак не отразилось. Тогда, если пользователь является профессионалом в проблемной области, он не может физически совершить какую-либо из типичных ошибок пользователя:

1) ввести данные неправильного типа или формата;

2) ввести данные не туда;

3) забыть сохранить файл данных;

4) сохранить файл данных так, что потом система его не найдет;

5) потерять, испортить, стереть файл;

6) дать неправильную команду (их просто не существует);

7) задать неверный режим;

8) потерять результаты;

9) получить результаты, непригодные для использования;

10) «подвесить» программу и многое, многое другое.

Более того у пользователя не должно возникать вопросов при работе с программной системой, поэтому нет необходимости в HELP-файлах, «горячих клавишах».

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

Рассмотрим некоторые положения этой технологии:

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

2) Идеальный случай – программный продукт не содержит управляющих клавиш. Активны лишь алфавитно–цифровые клавиши, клавиши управления курсором, клавиша ENTER

3) Идеальный случай — программный продукт не содержит управляющих команд (никаких F10, CTRL+B, ALT+X, ESC). Управление вводом-выводом осуществляет сама программа с помощью встроенного в него Анализатора экрана.

Правда, элементарная вежливость требует спросить пользователя, не возражает ли он против очередного действия программы, но это уже относится к области диалога.

4) Диалог должен быть типа “Короткий вопрос — Короткий ответ” (SQSA). Например, если по мнению Анализатора, ввод исходных данных завершен, то на экране будет выведен следующий вопрос:

Такое оконное микроменю обычно не вызывает затруднений у пользователя. Для ответа достаточно воспользоваться клавишами управления курсором, а затем нажать ENTER. В случае НЕТ ничего не происходит, и пользователь продолжает ввод или редактирование до следующего срабатывания Анализатора. В случае ДА файл исходных данных запоминается

Вопрос должен быть предельно коротким и ясным, а из возможных ответов допустимы лишь ДА и НЕТ. Максимально возможное число выводимых подряд оконных микроменю не более трех. Программа, задающая свыше трех вопросов подряд, вызывает у пользователя раздражение.

5) Следует иметь только одно (главное) меню. Причем оно должно содержать 5-6 пунктов и быть одноуровневым. Если же после выбора пункта меню у программной системы останутся вопросы, то их можно уточнить позднее, в форме «Кратких вопросов» (SQSA). Оптимальным считается простейшее вертикальное меню типа NORTON, распложенное в центре экрана на нейтральном фоне.

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

6) Создание новых файлов должна выполнять программная система, а не пользователь. При этом ставить об этом в известность пользователя нет необходимости. И не в коем случае пользователь не должен присваивать файлу имя. Оптимальным вариантом является извлечение имени файла из какого-либо поля вводимых данных этого файла.

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

Если программная система предусматривает выбор и загрузку одного из ранее созданных пользователем файлов, не желательно приводить в меню одни только их имена. К имени файла весьма уместен комментарий (приблизительно на 40-50 символов). Комментарий извлекается из какого-либо поля файла данных. Полезна также датировка.

G_KOLON	Деталь изделия ПМГ-10	12.05.92
G_RUCH	Деталь изделия Д-700	05.07.92
G_BAL	Деталь изделия ПМГ-10	01.11.12

Если пользователь не задает имени файла, то его присваивает система со специальными символами. Например, ## DDMMYY, где DD.MM.YY- показания системного таймера, а ## — порядковый номер сеанса или файла, созданного в указанный день. В этом случае меню выбора для пользователя выглядит так:

Сеанс 07 от 25 июня 1992 года

Сеанс 01 от 29 июня 1992 года

При выходе из системы файл должен быть сохранен автоматически.

7) Ввод данных должен проводиться по «по бумажному», т.е. экран полностью, до деталей, копирует знакомый пользователю бланк или документ. Следует стараться организовать экран так, чтобы в любой момент работы у пользователя не возникала необходимость произвести сложный скроллинг экрана. Иначе говоря, для ввода или получения справки он должен пользоваться только стрелками ”←“, ”→”, “↑”, “↓”.

Следует избегать многооконных экранов ввода (окна необходимы только для ввода сообщений и запросов программы). В тех случаях, когда многооконность неизбежна, следует ее «маскировать». Например, если бланк исходных данных не помещается на экране целиком, так как копирует весьма обширную ведомость, снабженную “шапкой” и “боковиком”, организует скроллинг, но «шапка» и “боковик” при этом остаются на экране. Это реализуется методом неподвижных окон. Но поскольку окна выполнены в той же палитре и в том же дизайне, что и основной экран ввода, то экран воспринимается пользователем как единое целое.

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

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

Следует отслеживать поля — антагонисты (если они есть) или коррелирование поля. Комплементарные поля (взаимодействующие поля как ключ-замок) должны заполняться оба или оба не задаваться.

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

Следует блокировать ненужные пользователю клавиши программным путем. Не должны влиять на ход вычислений случайные нажатия клавиш ESC, BREAKE и т.п.. В сложных системах следует применять динамическое (в зависимости от шага) блокирование клавиш.

8) Вывод результатов должен состоять из нескольких этапов. Первоначально они должны выводиться на экран (без всяких команд) для просмотра. Вывод результата также следует оформить «по-бумажному». Затем должна выводиться документация на печать в форме, которая не требует дополнительного редактирования.

Если выводиться несколько файлов, то желательно их выводить на экран все с помощью скроллинга.

Когда просмотр результата, по мнению Анализатора, закончен, то на экране можно вывести вопрос:

В случае НЕТ просмотр продолжается либо следует окончить сеанс. По окончании печати документов полезно повторить запрос, поскольку документы печатаются в нескольких экземплярах:

Результирующие файлы должны быть сохранены на диске, не ожидая указаний пользователя.

В программах вывода необходимо предусматривать все возможные сбои периферийного устройства вывода (типа PAGER OUT). Они не должны приводить к сбоям или зависаниям программной системы.

Технология создания программного продукта.

7) Виды памяти, модель внешней памяти, организация обмена данными между оперативной и внешней памятью.

8) Функции, принципы и способы построения ПО САПР и реализации в них типовых алгоритмов проектирования.

9) Этапы жизненного цикла программ.

10) Особенности технологии программирования сложных программных комплексов.

Воспользуйтесь поиском по сайту:

studopedia.org — Студопедия.Орг — 2014-2023 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.012 с) .

Источник: studopedia.org