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

 

Классификация программных продуктов по функциональному признаку

 

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

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

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

Оболочки (например, Norton Commander) в свое время появились для организации более удобного интерфейса пользователя с файловой системой MS DOS. Современные оболочки, такие, как Far, используют для обеспечения пользователю привычной среды при работе с файловой системой.

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

Прикладные программы и системы ориентированы на решение конкретных пользовательских задач.

Различают пользователей:

•   разработчиков программ;

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

Разработчики программ используют специальные инструментальные средства, такие как компиляторы, компоновщики, отладчики, которые последнее время обычно интегрируют в системы программирования (среды разработки). Современные среды программирования, например, Delphi, Visual С++, реализуют визуальную технологию разработки программных продуктов и предоставляют программистам огромные библиотеки компонентов, которые можно включать в свою разработку. К этой же группе относят также системы управления базами данных (СУБД) например, Access, FохРrо, Огас1е, средства создания интеллектуальных систем, например, экспертных, обучающих, систем контроля знаний и т. д. Последнее достижение в этом направлении - САSЕ-средства разработки программного обеспечения, такие как ERwin, BPwin, Paradigm Plus, Rational Rose и др.

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

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

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

•   системы автоматизации проектирования, ориентированные на различные технические области;

•   системы-тренажеры, например, тренажер для отработки действий пилотов в аварийной ситуации;

•   бухгалтерские системы, например, 1С;

•   издательские системы, например, РаgеМаkеr, QuarkXpress;

•   профессиональные графические системы, например, Adobe Illustrator, PhotoShop, CorelDraw;

•   экспертные системы и т. д.

Системы автоматизации производственных процессов отличаются от профессиональных тем, что они ориентированы на пользователей разных профессий, связанных единым производственным процессом.

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

К развлекающим относят игровые программы, музыкальные программы, опять же информационные системы, но с тестами развлекающего характера, например гороскопы и т. п.

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

 

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

 

Основные эксплуатационные требования к программным продуктам

Эксплуатационные требования определяют некоторые характеристики разрабатываемого программного обеспечения, проявляемые в процессе его функционирования. К таким характеристикам относят:

•   правильность - функционирование в соответствии с техническим заданием;

•   универсальность - обеспечение правильной работы при любых допустимых данных и защиты от неправильных данных;

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

•   проверяемость - возможность проверки получаемых результатов;

•   точность результатов - обеспечение погрешности результатов не выше заданной;

•   защищенность - обеспечение конфиденциальности информации;

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

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

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

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

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

•   реентерабельность - возможность «параллельного» использования несколькими процессами.

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

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

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

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

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

Часто самым «ненадежным элементом» современных систем являются люди. Уже хорошо известно, что в условиях монотонной работы за пультом вычислительной установки операторы допускают большое количество ошибок. Известны и средства, позволяющие снизить количество ошибок в конкретных ситуациях. Так, там, где это возможно, используют ввод избыточной информации, позволяющий выполнять проверки правильности вводимых данных (ввод контрольных сумм и т. п.). Кроме этого, широко используют всякого рода подсказки, когда информацию необходимо не вводить, а выбирать из некоторого списка и т. п.

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

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

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

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

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

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

Эффективность системы обычно оценивается отдельно по каждому ресурсу вычислительной установки. Часто используют следующие критерии:

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

•   объем оперативной памяти - для продуктов, работающих в системах с ограниченным объемом оперативной памяти, например МS DОS;

•   объем внешней памяти - для продуктов, интенсивно использующих внешнюю память, например баз данных;

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

Требования эффективности могут противоречить друг другу. Например, чтобы уменьшить время выполнения некоторого фрагмента программы, может потребоваться дополнительный объем оперативной памяти.

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

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

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

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

Разработка технического задания

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

На техническое задание в РФ действуют два стандарта  ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению» и  ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы (КСАС). Техническое задание на создание автоматизированной системы». Рассмотрим первый из них. В соответствии с этим стандартом техническое задание должно содержать следующие разделы:

•  введение;

•  основания для разработки;

•  назначение разработки;

•  требования к программе или программному изделию;

•  требования к программной документации;

•  технико-экономические показатели;

•  стадии и этапы разработки;

•  порядок контроля и приемки.

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

Рассмотрим более подробно содержание каждого раздела.

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

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

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

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

•   требования к функциональным характеристикам;

•   требования к надежности;

•   условия эксплуатации;

•   требования к составу и параметрам технических средств;

•   требования к информационной и программной совместимости;

•   требования к маркировке и упаковке;

•   требования к транспортированию и хранению;

•   специальные требования.

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

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

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

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

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

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

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

В разделе Стадии и этапы разработки указывают стадии разработки, этапы и содержание работ с указанием сроков разработки и исполнителей.

В разделе Порядок контроля и приемки указывают виды испытаний и общие требования к приемке работы.

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

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

В случаях, если какие-либо требования, предусмотренные техническим заданием, заказчик не предъявляет, следует в соответствующем месте указать «Требования не предъявляются».

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

Принципиальные решения этапа анализа требований

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

•  выбор архитектуры программного обеспечения;

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

•  выбор подхода к разработке (структурного или объектного);

•  выбор языка и среды программирования.

Другими словами, эти решения определяют, что проектируется, с какими потребительскими характеристиками, как и какими средствами.

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

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

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

•  многопользовательскую архитектуру, которая рассчитана на работу в локальной или глобальной сети.

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

•  программы;

•  пакеты программ;

•  программные комплексы;

•  программные системы.

Многопользовательскую архитектуру реализуют системы, построенные по принципу «клиент-сервер».

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

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

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

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

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

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

Сервер — программное обеспечение, принимающее запросы от клиентов.

Сервер — компьютер (или специальное компьютерное оборудование), выделенный и/или специализированный для выполнения определенных сервисных функций.

Клиент  — аппаратный или программный компонент вычислительной системы, посылающий запросы серверу

Выбор типа пользовательского интерфейса. Различают четыре типа пользовательских интерфейсов:

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

•  меню - реализуют множество сценариев работы, операции которых организованы в иерархические структуры, например, «вставка»: «вставка файла», «вставка символа» и т. д.;

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

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

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

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

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

•   однодокументная, которая предполагает однодокументный интерфейс(SDI – Single Document Interface);

•   многодокументная, которая предполагает многодокументный интерфейс (MDI – Multiple Document Interface).

Многодокументную технологию используют, если программное обеспечение должно работать с несколькими документами одновременно, например, с несколькими текстами или несколькими изображениями. Однодокументную - если одновременная работа с несколькими документами не обязательна.

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

Выбор подхода к разработке. Если выбран интерфейс со свободной навигацией или прямого манипулирования, то, как указывалось выше, это практически однозначно предполагает использование событийного программирования и объектного подхода, так как современные среды визуального программирования, такие как Visual С++, Delphi,   Builder С++ и им подобные, предоставляют интерфейсные компоненты именно в виде объектов библиотечных классов. При этом в зависимости от сложности предметной области программное обеспечение может реализовываться как с использованием объектов и, соответственно, классов, так и чисто процедурно. Исключение составляют случаи использования специализированных языков разработки Интернет-приложений, таких как Реr1, построенных по совершенно другому принципу.

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

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

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

Во всех прочих случаях выбор подхода остается за разработчиком.

Выбор языка программирования. В большинстве случаев никакой проблемы выбора языка программирования реально не существует. Язык может быть определен:

·         организацией, ведущей разработку; например, если фирма владеет лицензионным вариантом Visual Studio , то она будет вести разработки преимущественно в данной среде;

·         программистом, который по возможности всегда будет использовать хорошо знакомый язык;

·         устоявшимся мнением («все разработки подобного рода должны выполняться на С++ или на Java или на ...») и т. п.

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

·         универсальные языки высокого уровня;

·         специализированные языки разработчика программного обеспечения;

·         специализированные языки пользователя;

·         языки низкого уровня.

В группе универсальных языков высокого уровня безусловным лидером на сегодня является С-подобные языки. Действительно различные версии С, C#, С++, Java имеют целый ряд очень существенных достоинств:

·         многоплатформенность - для всех используемых в настоящее время платформ существуют компиляторы для этих языков;

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

·         возможность программирования на низком (системном) уровне с использованием адресов оперативной памяти;

·         огромные библиотеки подпрограмм и классов.

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

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

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

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

Альтернативой С и С++ среди универсальных языков программирования, используемых для создания прикладного программного обеспечения являются языки C#  и Java. Кроме этого относительно активно используется Pascal, компиляторы которого в силу четкого синтаксиса обнаруживают помимо синтаксических и большое количество семантических ошибок. Версия Object Pascal, использованная в среде Delphi, сопровождается профессиональными библиотеками классов, упрощающими ведение больших разработок, в том числе и требующих использования баз данных, что делает Delphi достаточно эффективной средой для создания приложений Windows.

Историю языков программирования высокого уровня традиционно ведут с появления (1957 г.) языка Фортран (FORTRAN от FORmula TRANslator). Благодаря развитию этого языка появились подпрограммы - предвосхитив идею модульного программирования. Это язык был создан для упрощения программирования математических формул. Первым универсальным языком высокого уровня считается язык ALGOL 60 (1960 г., ALGOrithmic Language). В 1962 г. по заказу министерства обороны США был разработан язык COBOL (Common Business Oriented Language), в котором учитывалась специфика обработки именно коммерческих данных. Чтобы преломить тенденцию разделения языков программирования на научную и коммерческую области применения, корпорация IBM в 1967 году создала язык  PL/1, который вобрал в себя все от языков FORTRAN, ALGOL,  COBOL и был независим от области применения.

Кроме того, к самым известным языкам программирования относят Basic, Pascal, (наследник Алгола), Simula 67, LISP, Modula, Prolog, Ada, Smolltalk (первый объектно-ориентированный язык).

 

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

·         языки баз данных;

·         языки создания сетевых приложений;

·         языки создания систем искусственного интеллекта и т. д.

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

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

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

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

В настоящее время языки типа Ассемблера обычно используют:

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

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

 

Языки высокого уровня (high-level language) понятнее человеку. В них не учитываются особенности компьютерных архитектур, они представляют мощный механизм описания алгоритмов в той форме, в которой их можно вводить непосредственно в ЭВМ. Один оператор языка высокого уровня порождает группу машинных команд.

 

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

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

Наиболее часто используемыми являются визуальные среды Delphi, С++ Builder фирмы Borland, Visual  Studio фирмы Microsoft, Visual Ada  фирмы IВМ и др.

Между основными визуальными средами этих фирм Delphi, С++ Builder и Visual  С++  имеется существенное различие: визуальные среды фирмы Microsoft, обеспечивают более низкий уровень программирования «под Windows». Это является их достоинством и недостатком. Достоинством -так как уменьшается вероятность возникновения «нестандартной» ситуации, т.е. ситуации, не предусмотренной разработчиками библиотеки компонентов, а недостатком - так как это существенно загружает программиста «рутинной» работой, от которой избавлен программист, работающий с Delphi или С++ Builder.

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

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

·         стандарт проектирования;

·         стандарт оформления проектной документации;

·         стандарт интерфейса пользователя.

Стандарт проектирования должен определять:

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

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

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

·         механизм обеспечения совместной работы над проектом, в том числе и правила  интеграции подсистем проекта и анализа проектных решений на непротиворечивость.

Стандарт оформления проектной документации должен регламентировать

·           комплектность, состав и структуру документации на каждой стадии;

·           требования к ее содержанию и оформлению;

·           правила подготовки, рассмотрения, согласования и утверждения документов.

Стандарт интерфейса пользователя должен определять:

·         правила оформления экранов (шрифты и цветовую палитру), состав и расположение окон и элементов управления;

·         правила пользования клавиатурой и мышью;

·         правила оформления текстов помощи;

·         перечень стандартных сообщений;

·         правила обработки реакции пользователя.

 

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

Приложение1.

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

 

Пример1. Разработать техническое задание на программный продукт,  предназначенный для наглядной демонстрации школьникам графиков (функций одного аргумента у = f(х)). Разрабатываемая программа должна раccчитывать таблицу значений и строить график функций на заданном отрезке по  заданной формуле и менять шаг аргумента и границы отрезка. Кроме того, программа должна запоминать введенные формулы.

1. ВВЕДЕНИЕ

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

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

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

Разрабатываемая программа позволит школьникам проверить свои знания при изучении указанной темы.

2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

Программа разрабатывается на основе учебного плана кафедры ТОИиИТ и в соответствии с договором кафедры со школой № 5 от 09.09.2005.

3. НАЗНАЧЕНИЕ

Основным назначением программы является помощь школьникам при изучении раздела «Исследование функций одного аргумента» школьного курса элементарной алгебры.

4. ТРЕБОВАНИЯ К ПРОГРАММЕ ИЛИ ПРОГРАММНОМУ ИЗДЕЛИЮ

4.1.Требования к функциональным характеристикам

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

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

4.1.2.    Исходные данные:

• аналитическое задание функции;
• интервал определения функции;
• шаг изменения аргумента, определяющий количество точек на интервале.

4.2.       Требования к надежности

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

4.3.       Требования к составу и параметрам технических средств

Система должна работать на IВМ совместимых персональных компьютерах.

Минимальная конфигурация:

 

• тип процессора            Pentium  и выше;
• объем оперативного запоминающего устройства        32 Мб и более.

4.4.       Требования  к  информационной  и  программной совместимости

Система должна работать под управлением семейства операционных систем Win 32 (Windos 95, 98, 2000, NT, XP).

5. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

5.1. Разрабатываемые программные модули должны быть самодокументированы, т. е. тексты программ должны содержать все необходимые комментарии.

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

5.3. В состав сопровождающей документации должны входить:

5.3.1. Пояснительная записка на 25-30 листах, содержащая описание разработки

5.3.2. Руководство пользователя.

Приложение 2.

Пример оформления титульного листа ТЗ

 

Министерство образования и науки РФ

государственный технический университет

Международный факультет прикладных информационных технологий

Кафедра «Прикладная информатика и программная инженерия»

УТВЕРЖДАЮ Зав. кафедрой ПИН

Д.ф.-м.н., доцент          

«__»_____________2020 г.

ПРОГРАММА ПОСТРОЕНИЯ ТАБЛИЦ И ГРАФИКОВ ФУНКЦИИ

Техническое задание на курсовую работу

Листов 5

 

 

 

 

 

Руководитель

 д. ф.-м.н., доцент  

Исполнитель

студент 2 курса  группы

 

 

 

 

 

 

Контрольные вопросы по теме

1.       Что такое функциональные и эксплуатационные требования к ПО?

2.       Какие программные продукты относятся к системным?

3.       Какие программные продукты относятся к прикладным?

4.       Какие программные продукты относят к гибридным?

5.       Что означает эксплуатационное требование правильности ПО?

6.       Что означает эксплуатационное требование универсальности ПО?

7.       Что означает эксплуатационное требование надежности  ПО?

8.       Что означает эксплуатационное требование проверяемости ПО?

9.       Что означает эксплуатационное требование точности результатов ПО?

10.    Что означает эксплуатационное требование защищенности ПО?

11.    Что означает эксплуатационное требование программной совместимостиПО?

12.    Что означает эксплуатационное требование аппаратной совместимости ПО?

13.    Что означает эксплуатационное требование эффективности ПО?

14.    Что означает эксплуатационное требование адаптируемости ПО?

15.    Что означает эксплуатационное требование повторной входимости ПО?

16.   Что означает эксплуатационное требование реентерабельности ПО?

17.   Что такое техническое задание на разработку ПО?

18.   Какие ГОСТы на техническое задание Вы знаете?

19.   Перечислите и охарактеризуйте основные разделы технического задания.

20.   Какие принципиальные решения должны быть приняты на этапе анализа требований

21.   Что такое однопользовательская и многопользовательская архитектура ПО?

22.   Какие типы программных продуктов различают в рамках однопользовательской архитектуры?

23.   Охарактеризуйте  архитектуру типа «клиент-сервер».

24.   Назовите четыре типа пользовательского интерфейса, охарактеризуйте каждый из них.

25.   Что такое SDI и MDI?

26.   Перечислите наиболее известные языки программирования?

27.   Назовите первый язык программирования высокого уровня?

28.   Назовите первый объектно-ориентированный язык программрования?

29.   Перечислите особенности языка программирования высокого уровня.

30.   Перечислите особенности языка программирования низкого уровня.

31.   Что относят к специализированным языкам разработки ПП?

32.   Что определяет стандарт проектирования разработки ПП?

33.   Что определяет стандарт оформления проектной документации ПП?

34.   Что определяет стандарт интерфейса пользователя ПП?