Технология программирования
| Вид материала | Документы |
- Лекция 4 Тема 3 Технология программирования и основные этапы ее развития, 46.22kb.
- Программа как формализованное описание процесса обработки данных. Программное средство., 362.79kb.
- Календарный план учебных занятий по дисциплине «Языки и технология программирования», 43.35kb.
- Программа обучения студентов (Syllabus) по дисциплине тр302- технология программирования, 375.44kb.
- Программа курса "Технология программирования и управление программными проектами", 100.25kb.
- Курсовой проект по курсу «Технология программирования», 147.33kb.
- Рабочая программа дисциплины: б б 7 Конструирование программного обеспечения для направления, 156.05kb.
- В. А. Основы объектного программирования на языке C# оо – технология и обучение программированию, 141.07kb.
- Рабочая учебная программа по дисциплине «Технология программирования» Направление №230100, 109.02kb.
- Технологии программирования, 30.41kb.
Вопрос №2 Принципы проектирования информационного обеспечения программного комплекса.
С точки зрения готового решения система должна удовлетворять следующим требованиям:
- Соответствие уставу проекта/техническому заданию.
- Адекватность отображения предметной области. Для соблюдения этого очевидного принципа необходимо тесное взаимодействие проблемного пользователя и программиста. Оценить адекватность может только квалифицированный специалист в данной проблемной области.
- Возможность подготовки информации для принятия решений в условиях творческого неформализуемого процесса. Здесь, прежде всего, система должна давать возможность ответа на неизвестные заранее запросы пользователя.
- Возможность постоянного расширения предоставляемых пользователю срезов информации. В процессе использования системы растет желание пользователя по расширению круга получаемой информации.
- Адаптируемость к изменяющимся условиям. В процессе жизни системы изменяются предметная область, желания пользователя, технические и программные средства и т.п.
- Способность функционировать в условиях человеческой деятельности. Человеческая деятельность в значительной степени осуществляется не по формальным правилам, многое зависит от конкретного субъекта. Система должна функционировать в соответствующих условиях.
- Обеспечение проверки достоверности данных при вводе в систему. При вводе данных пользователь может делать как случайные, так и преднамеренные ошибки. Система должна контролировать ввод данных.
- Возможность взаимодействия с пользователями разных категорий и в разных режимах. Пользователи могут различаться по уровню знаний, по квалификации, по уровню доступа, по иерархии. Система должна учитывать соответствующие уровни и режимы работы.
- Технологичность обработки данных (дружественный интерфейс, приемлемые временные характеристики объекта и т.п.). Допустимое время отклика зависит от частоты запроса, сложности запроса и может меняться в широких пределах.
- Обеспечение секретности данных, надежности, целостности, защиты от случайного или преднамеренного разрушения.
^ При разработке системы необходимо учитывать следующие принципы:
1. Оптимизация времени на тестирование и отладку.
Тестирование и отладка программы – необходимый этап в процессе решения задачи на ЭВМ. Он занимает от трети до половины всего времени разработки программы, поэтому очень важно уменьшить время, затрачиваемое на тестирование и отладку.
Тестирование и отладка программы облегчается, если программа просто анализируется и снабжена необходимыми комментариями, облегчающими ее понимание. Хорошие комментарии могут ускорить процесс отладки. Еще один важный принцип – использование мнемонических обозначений для переменных. Языки программирования представляют здесь вполне достаточные возможности. Для лучшего понимания программы необходимо использовать мнемонику, отражающую физический (математический, экономический и т.д.) смысл переменной (например, SPEED - скорость).
2. Простота и "понятность" кода.
Разработанная и отлаженная система предназначена для многократного использования, и ее эксплуатацией, как правило, занимаются не разработчики, а другие программисты, входящие в так называемую группу сопровождения.
Программистам, сопровождающим систему, часто приходится продолжать отладку программы и производить ее модернизацию, в связи с изменением технического задания, введением новых средств программного обеспечения или выявлением новых ошибок и недоработок в программе. Для уменьшения затрат на сопровождение необходимо, чтобы каждый разработчик учитывал сложность сопровождения. Следует разрабатывать, отлаживать и оформлять программу с учетом того, что ее будут использовать и сопровождать другие программисты.
3. Гибкость системы.
Разработанная программа обычно находится в эксплуатации длительное время. За это время могут измениться требования к решаемой задаче, техническое задание, требования к программе. Появляется необходимость внести определенные изменения в программу, что в некоторых случаях бывает трудно сделать, т.к. разработчиком не предусмотрена такая возможность. "Хорошая" программа должна допускать модификацию.
4. Эффективность.
Эффективность программы считается одной из главных ее характеристик. Поэтому часто в ущерб другим качествам программы разработчики прибегают к сложным ухищрениям, чтобы уменьшить объем используемой памяти или сократить время выполнения программы. Во многих случаях затрачиваемые на это усилия не оправдывают себя. Разумный подход к повышению эффективности программы состоит в том, чтобы выявить наиболее "узкие" места и постараться их улучшить.
^
Вопрос №3 Показатели качества программного обеспечения
Мы можем выделить следующие специфические для ПО показатели качества:
- функциональная полнота
- удобство
- надежность
- техническая эффективность
- адаптивность
- стоимость
функциональная полнота
Данный показатель характеризует степень удовлетворения потребностей пользователя в смысле возможности решения конкретных задач, стоящих перед ним. Функциональную полноту можно рассматривать в виде арифметической дроби, в числителе которой находится число, равное количеству функций, реализуемых программной системой, а в знаменателе записывается число функций, требующихся пользователю. Очевидно, что оптимальным значением функциональной полноты является 1. Если этот показатель больше единицы, то имеется функциональная избыточность; в противном случае возникает функциональная недостаточность. В любых случаях, когда функциональная полнота не равна 1, ПО, тем не менее, пригодно к эксплуатации.
При функциональной недостаточности ПО пользователю приходится либо отказаться от решения некоторых задач, либо решать их с большими затратами, например, достигая цели не за один, а за несколько шагов. Может показаться, что функционально избыточные системы всегда предпочтительнее функционально недостаточных. Это далеко не всегда справедливо. Действительно, первые системы всегда дороже вторых и требуют больших вычислительных ресурсов. Кроме того, их изучение и использование вызывает дополнительные затруднения пользователя, а это приводит к тому, что некоторые дублирующие друг друга функции вообще не будут использоваться и, сл-но, попросту будут лишними.
удобство
С точки зрения удовлетворения потребительского спроса это показатель качества может иногда оказать решающее влияние на выбор того или иного ПО. Практика показывает, что конечный пользователь, не имеющий спец.подготовки в области программирования, просто-напросто не будет использовать программу, если она оказывается не удобной для него.
Удобство использования ПО характеризуют следующие показатели:
- время реакции системы
- количество информации, предъявляемой системой, которое необходимо переработать пользователю
- количество действий, предпринимаемых пользователем при работе с ПО
- эстетика оформления результатов работы
- время освоения приемов работы с ПО
1. Время реакции системы
Например, если ПО предназначен для работы с человеком в режиме диалога, то время реализации любой команды пользователя должно быть соизмеримо с естественной скоростью протекания психофизиологических реакций человека. Вряд ли поэтому надо требовать время ответа системы за интервал, меньший нескольких десятых долей секунды – если даже система и будет реагировать скорее, человек не уловит этого. Поэтому подход к оценке данного критерия следовало бы сформулировать так: показатель тем лучше, чем он ближе к заданному интервалу времени, необходимому для решения задачи.
^ 2. Количество информации, предъявляемое системой, которое необходимо переработать пользователю
С точки зрения количества информации, которое пользователь должен переработать для того, чтобы оценить результаты и принять решение, всегда лучше та система, где это количество меньше. Поэтому разработчик ПО должен проектировать систему с таким расчетом, чтобы представлять пользователю лишь минимально необходимые для его работы сведения и данные. Дополнительную или справочную информацию следует выдавать лишь по желанию пользователя.
^ 3. Количество действий, предпринимаемых пользователем при работе с ПО
Точно также лучшим может считать такое ПО, которое требует от пользователя минимальных действий за пультом. Например, типичная ситуация при работе с диалоговыми системами состоит в выборе какой-либо одной функции из нескольких возможных.
Система может быть построена так, что для выбора нужно будет напечатать наименование функций; в другом варианте требуется ввести ее номер; в третьем, достаточно установить курсор в нужное положение. По-видимому, наиболее удобным следует считать именно третий вариант. Кстати, он будет и наиболее надежным.
^ 4. Эстетика оформления результатов работы
Важную роль в точки зрения положительных (или отрицательных) эмоций пользователя играет эстетическая сторона оформления результатов работы ПО. Небрежная печать с невыровненными строками, невыдержанные колонки цифр, неумело подобранные цвета экранного изображения могут вызывать дополнительное утомление пользователя, раздражение и, сл-но, отрицательное отношение к ПО.
^ 5. Время освоения приемов работы с ПО
Время освоения пользователем ПО также является одним из важнейших показателей удобства ПО. Чем меньше это время, тем проще ПО для использования, сл-но, тем он лучше, удобнее. Рассмотрим пример двух диалоговых систем. В первой системе все приемы работы изложены в печатной инструкций; во второй - они выводятся в виде оперативных подсказок на экране. Очевидно, что вторая система удобнее: не нужно держать в памяти возможные варианты действий или рыться в инструкции, теряя время и отвлекаться от экрана.
Надежность
Можно выделить два основных аспекта надежности:
- отсутствие в готовой программе ошибок проектирования и программирования
- защищенность программы от непредусмотренных условий эксплуатации
^ 1. Отсутствие в готовой программе ошибок проектирования и программирования
Ошибки проектирования возникают потому, что разработчик неточно понял требования заказчика, в результате чего готовая программа выполняет не все требующиеся функции, или не так, как подразумевалось. Как следствие возникает функциональная недостаточность ПО. Эти ошибки весьма сложно устранить, поскольку они связаны с изменением алгоритмов.
Оценить величину надежности принципиально можно вероятностью отсутствия ошибок, но теоретически определить эту вероятность, найти ее числовое значение пока не удается. Тем не менее при практической эксплуатации ПО можно вынести суждение об уровне надежности методом экспертных оценок.
^ Ошибки программирования возникают вследствие либо небрежности, либо недостаточной квалификации программиста при записи алгоритмов на языке программирования. Эти ошибки сравнительно легко устраняются, однако оценить их наличие так же трудно, как и в предыдущем случае.
^ 2. Защищенность программы от непредусмотренных условий эксплуатации
Другой аспект надежности заключается в степени защищенности ПО от:
- непредусмотренных действий пользователя
- недопустимых сочетаний исходных данных
- влияние операционного окружения
Наибольшее влияние непредусмотренные действия пользователя оказывают на вычислительный процесс при работе в диалоговом режиме. Надежная программа не реагирует на нажатие неразрешенных клавиш, ненадежная программа может завершиться аварийно, поставив пользователя в трудное положение.
Не совершая неправильных действий за пультом, пользователь, тем не менее, может ввести недопустимое сочетание исходных данных, приводящих к аварийному завершению программы, например, вследствие деления на ноль или выхода индексов за описанные границы. Надежная программа должна выполнять соответствующие проверки и не допускать вычислений с этими данными, а предупреждать пользователя о невозможности выполнения его требований и возвращаться в исходное состояние.
Наиболее сложно защитить программу от влияния непредусмотренного операционного окружения, в частности «компьютерных вирусов». Однако, отдавая отчет, что любой вирус обычно увеличивает длину поражаемой программы, можно так построить ПО, чтобы, по крайней мере, выдавалось бы предупреждение о том, что программа заражена и блокировалась бы возможность ее выполнения.
Для обеспечения надежности в смысле защиты от перечисленных факторов необходимо использовать соответствующие приемы программирования: анализ возвращаемых кодов клавиатуры, синтаксический анализ команд или ответов пользователя, семантический анализ вводимых данных.
техническая эффективность
Этот показатель характеризует объемы требующихся ресурсов вычислительной системы:
объем оперативной памяти
объем внешней памяти
время работы процессора
привлекаемые компоненты операционной системы
Практически все эти показатели могут получить числовую оценку. Однако, далеко не всегда справедливо утверждение: чем меньше, тем лучше. Ведь его можно легко довести до абсурда, например, сказав, что лучше всего такое ПО, которое требует ноль байтов оперативной памяти или ноль секунд процессорного времени.
Тем не менее, верно следующее: из двух программ с одинаковыми функциональными свойствами лучше та, которая потребляет меньше ресурсов. Но и в этом плане надо иметь в виду, что абсолютная величина ресурсов не дает достаточно полной информации. Например, если одна программа требует 30 килобайтов основной памяти, а другая – 60, то в случае работы на ПЭВМ, это различие не играет никакой роли. Хотя в то же время вторая программа потребует, по- видимому, большего объема внешней памяти и в этом плане ее показатели хуже.
Адаптивность
Под адаптивностью ПО подразумевается возможность его модификации в случае изменения параметров решаемых задач операционного окружения, аппаратурного состава или вообще типа ЭВМ. При изменении характера и параметров решаемых задач, как правило, требуется изменить количественные и структурные параметры программы. Эти изменения можно сделать либо изменяя управляемые параметры программы, если она является параметрической, либо изменяя ее исходный текст.
Естественно, уровень адаптивности в первом случае значительно выше, чем во втором. Если же ПО не снабжен исходными текстами, то изменить загрузочный модуль программы – задача высшей категории сложности и, сл-но, такую программу можно рассматривать, как неадаптируемую.
Мощным методом адаптации ПО является генерация – процесс сборки и настройки рабочей версии ПО из заведомо избыточного набора программных модулей. Обычно генерируемые ПО являются наиболее сложными программными системами, как например, СУБД. Уровень адаптируемости таких ПО следует считать весьма высоким.
Наиболее сложные задачи адаптации возникают при переносе ПО с ЭВМ одного типа на другую. Естественно, такой перенос возможен только на уровне исходных текстов, так, что ПО представленный только загрузочным модулем заведомо непереносим.
Однако и версии языков программирования высокого уровня, как, например, Фортран или Паскаль, отличаются для машин различных типов, вследствие чего перенос ПП как правило сопровождается переработкой исходных текстов.
Стоимость
С точки зрения потребителя следует различать два аспекта показателя: стоимость приобретения и стоимость эксплуатации.
В этом плане пользователь всегда стоит перед дилеммой: приобрести типовое готовое ПО или заказать индивидуальную разработку. В первом случае стоимость приобретения сравнительно невелика, однако адаптация ПП, его настройка на класс решаемых задач потребует определенных затрат. Созданное по индивидуальному заказу ПО как правило заметно дороже готового, но полнее отвечает требованиям пользователя. В этом случае стоимость его приобретения значительно выше, но стоимость настройки и эксплуатации существенно ниже, чем в первом варианте. В общем, для различных практических ситуаций перечисленные выше показатели качества ПО имеют различное значение; в одних случаях наиболее важным свойством может оказаться удобство или надежность, а в других – технические показатели или стоимость.