1 Определение требований к программному обеспечению и исходных данных для его проектирования Системное и прикладное программное обеспечение Малышенко Владислав Викторович

2 Классификация программных продуктов по их назначению Программные продукты Системные Прикладные Гибридные Операционные системы Оболочки Утилиты Автоматизированные системы управления реального времени Для разработчиков программ Для непрограммистов CASE-средства Среды разработки Системы программирования Отладочные средства Общего назначения Профессиональные Системы автоматизации производственных процессов Обучающие Развлекающие

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

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

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

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

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

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

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

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

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

12 ГОСТ «Техническое задание. Требования к содержанию и оформлению». В соответствии с этим стандартом техническое задание должно содержать следующие разделы: введение; основания для разработки; назначение разработки; требования программному изделию; требования к программной документации; технико-экономические показатели; стадии и этапы разработки; порядок контроля и приемки.

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

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

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

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

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

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

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

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

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

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

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

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

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

26

27 1. ВВЕДЕНИЕ Настоящее техническое задание распространяется на разработку программы построения графиков и таблиц значений функций одной переменной, предназначенной для использования школьниками старших классов. В школьном курсе элементарной алгебры тема анализа функций является одной из самых сложных. При изучении данной темы школьники должны научиться исследовать и строить графики функций одной переменной, используя все известные характеристические точки функции, включая корни, точки разрыва первого и второго рода и т. д. Существующее программное обеспечение, которое может решать подобные задачи, является универсальным, например Eurica или MathCad. Оно имеет сравнительно сложный пользовательский интерфейс, ориентированный на пользователя, прослушавшего, как минимум, институтский курс высшей математики, что делает использование подобных средств школьниками невозможным. Разрабатываемая программа позволит школьникам проверить свои знания при изучении указанной темы.

28 2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ Программа разрабатывается на основе учебного плана кафедры «ЮНЕСКО по НИТ» и в соответствии с договором кафедры со школой13 от

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

30 4.ТРЕБОВАНИЯ К ПРОГРАММЕ ИЛИ ПРОГРАММНОМУ ИЗДЕЛИЮ 4.1.Требования к функциональным характеристикам Программа должна обеспечивать возможность выполнения следующих функций: ввод аналитического представления функции одной переменной и длительное хранение его в системе; ввод и изменение интервала определения функции; ввод и корректировку шага аргумента; построение таблицы значений функции на заданном интервале иди изображение графика функции на заданном интервале при условии, что на указанном интервале она не имеет точек разрыва.

31 4.ТРЕБОВАНИЯ К ПРОГРАММЕ ИЛИ ПРОГРАММНОМУ ИЗДЕЛИЮ Исходные данные: аналитическое задание функции; интервал определения функции; шаг изменения аргумента, определяющий количество точек на интервале.

32 4.ТРЕБОВАНИЯ К ПРОГРАММЕ ИЛИ ПРОГРАММНОМУ ИЗДЕЛИЮ 4.2. Требования к надежности Предусмотреть контроль вводимой информации Предусмотреть блокировку некорректных действий пользователя при работе с системой.

33 4.ТРЕБОВАНИЯ К ПРОГРАММЕ ИЛИ ПРОГРАММНОМУ ИЗДЕЛИЮ 4.3. Требования к составу и параметрам технических средств Система должна работать на IBM совместимых персональных компьютерах Минимальная конфигурация: тип процессора Pentium и выше; объем оперативного запоминающего устройств 32 Мб и более.

34 4.ТРЕБОВАНИЯ К ПРОГРАММЕ ИЛИ ПРОГРАММНОМУ ИЗДЕЛИЮ 4.4. Требования к информационной и программной совместимости Система должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, Windows 2000, Windows NT и т. п.).

35 5. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ 5.1. Разрабатываемые программные модули должны быть самодокументированны, т. е. тексты программ должны содержать все необходимые комментарии Разрабатываемая программа должна включать справочную информацию об основных терминах соответствующего раздела математики и подсказки учащимся В состав сопровождающей документации должны входить: Пояснительная записка на листах, содержащая описание разработки Руководство пользователя.

36 Возвращаясь к материалам лекции …

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

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

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

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

41 выбор технологии работы с документами Различают две технологии: однодокументная, которая предполагает однодокументный интерфейс (SDI – Single Document Interface); многодокументная, которая предполагает многодокументный интерфейс (MDI – Multiple Document Interface). Многодокументную технологию используют, если программное обеспечение должно работать с несколькими документами одновременно, например, с несколькими текстами или несколькими изображениями. Однодокументную - если одновременная работа с несколькими документами не обязательна. Трудоемкость реализации многодокументных интерфейсов с использованием современных библиотек примерно на % выше, чем первого.

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

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

44 Выбор языка программирования Язык может быть определен: организацией, ведущей разработку; например, если фирма владеет лицензионным вариантом C++ Builder, то она будет вести разработки преимущественно в данной среде; программистом, который по возможности всегда будет использовать хорошо знакомый язык; устоявшимся мнением («все разработки подобного рода должны выполняться на C++ или на Java или на...») и т. п.

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

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

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

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

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

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

51 Выбор среды программирования Средой программирования называют программный комплекс, который включает специализированный текстовый редактор, встроенные компилятор, компоновщик, отладчик, справочную систему и другие программы, использование которых упрощает процесс написания и отладки программ. Последнее время широкое распространение получили упоминавшиеся выше среды визуального программирования, в которых программист получает возможность визуального подключения к программе некоторых кодов из специальных библиотек компонентов, что стало возможным с развитием объектно- ориентированного программирования. Наиболее часто используемыми являются визуальные среды Delphi, C++ Builder фирмы Borland (Inprise Corporation), Visual C++, Visual Basic фирмы Microsoft, Visual Ada фирмы IBM и др.

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

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

54 Стандарт оформления проектной документации должен регламентировать: комплектность, состав и структуру документации на каждой стадии; требования к ее содержанию и оформлению; правила подготовки, рассмотрения, согласования и утверждения документов.

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

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