ЛР Введение в ПрогрИнж

Каким образом система будет способствовать целям бизнеса?

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

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

4.Распределить роли в группе (руководитель проекта-разработчик, системный аналитикразработчик, тестер-разработчик).

5.Заполнить разделы плана:

Введение Организация выполнения проекта Анализ рисков

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

6. Составить отчет о проделанной работе.

5.Содержание отчета

В отчете следует указать:

1.Цель работы

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

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

4.Анализ осуществимости (согласно требованиям к результатам выполнения лабораторного практикума п.2), указать возможные проблемы и пути их решения.

5.Роли участников группы разработки ПрИнС.

6.Программно-аппаратные средства, используемые при выполнении работы.

7.Заключение (выводы)

8.Список используемой литературы

6.Литература

1.Соммервиль Иан. Инженерия программного обеспечения, 6-е издание. : Пер. с англ. – М.: Издательский дом “Вильямс”, 2002. – 624 с.

2.Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.:Питер, 2002. – 496 с.

3.Константайн Л., Локвуд Л. Разработка программного обеспечения. – СПб.:Питер, 2004. – 592 с.

4.Иванова Г.С. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э.

Баумана, 2002. - 320 с.

Лабораторная работа № 2 «Разработка требований к программно-информационной системе»

1. Цель работы:

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

2. Методические указания

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

Требования к результатам выполнения лабораторного практикума:

1.наличие диаграммы идентификации точек зрения и диаграммы иерархии точек зрения;

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

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

4.наличие составленного технического задания.

3. Теоретические сведения Общие сведения о требованиях к программному обеспечению

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

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

Разработка требований

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

1.анализ технической осуществимости создания системы,

2.формирование и анализ требований,

3.специфицирование требований и создание соответствующей документации,

4.аттестация этих требований.

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

Рис. 1. Процесс разработки требований

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

Формирование и анализ требований

Следующим этапом процесса разработки требований является формирование (определение) и анализ требований.

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

Рис. 2. Процесс формирования и анализа требований

Процесс формирования и анализа требований проходит через ряд этапов.

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

2.Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

3.Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.

4.Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия различного рода.

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

6.Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

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

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

Опорные точки зрения

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

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

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

3.Как получатели системных сервисов. В этом случае точки зрения являются внешними

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

Наиболее эффективным подходом к анализу таких систем является использование внешних опорных точек зрения. На основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition — определение требований на основе точек зрения) для формирования и анализа требований. Основные этапы метода VORD показаны на рис. 3.:

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

2.Структурирование точек зрения — создание иерархии сгруппированных точек зрения. Общесистемные сервисы предоставляются более высоким уровням иерархии и наследуются точками зрения низшего уровня.

3.Документирование опорных точек зрения, которое заключается в точном описании идентифицированных точек зрения и сервисов.

4.Отображение системы точек зрения, которая показывает системные объекты, определенные на основе информации, заключенной в опорных точках зрения.

Рис. 3. Метод VORD

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

список всех товаров;

список товаров, имеющихся в наличии;

список товаров, количество которых необходимо пополнить;

список товаров, поставляемых данным поставщиком.

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

Рис. 4. Диаграмма идентификации точек зрения

В таблице 1 показано распределение сервисов для некоторых идентифицированных на рис. 4 точек зрения. Один и тот же сервис может быть соотнесен с несколькими точками зрения.

Таблица 1 - Сервисы, соотнесенные с точками зрения

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

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

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

Рис. 5. Иерархия точек зрения Аттестация требований

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

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

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

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

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

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

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

1.Обзор требований. Требования системно анализируются рецензентами.

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

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

4.Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства для проверки непротиворечивости моделей. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все

требования в этой базе данных. Анализатор требований готовит отчет обо всех обнаруженных противоречиях.

Пользовательские и системные требования

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

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

Далее составляются системные требования. Они включат в себя:

1.Требования к архитектуре системы. Например, число и размещение хранилищ и серверов приложений.

2.Требования к параметрам оборудования. Например, частота процессоров серверов и клиентов, объём хранилищ, размер оперативной и видео памяти, пропускная способность канала и т.д.

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

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

5.Требования к структуре системы. Например, Масштабируемость, распределённость, модульность, открытость.

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

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

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

4.Порядок выполнения работы

1.Изучить предлагаемый теоретический материал.

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

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

4.Провести аттестацию требований, указать какие типы проверок выбрали.

5.На основании описания системы (Лабораторная работа №1), программно-информационной модели, пользовательских и системных требований составить техническое задание на создание программного обеспечения (пример см. Приложение Б). ТЗ должно содержать основные разделы, описанные в ГОСТ 34.602-89 (см. Приложение А).

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

5.Содержание отчета

Вотчете следует указать:

1.Цель работы

2.Введение

3.Программно-аппаратные средства, используемые при выполнении работы.

4.Основная часть (описание самой работы), выполненная согласно требованиям к результатам выполнения лабораторного практикума (п.2).

5.Заключение (выводы)

6.Список используемой литературы

6.Литература

1.Соммервиль Иан. Инженерия программного обеспечения, 6-е издание. : Пер. с англ. – М.: Издательский дом “Вильямс”, 2002. – 624 с.

2.Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.:Питер, 2002. – 496 с.

3.Константайн Л., Локвуд Л. Разработка программного обеспечения. – СПб.:Питер, 2004. – 592 с.

4.Иванова Г.С. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э.

Баумана, 2002. - 320 с.

5.ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

6.ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению

Лабораторная работа № 3

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

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

Указания к выполнению лабораторной работы

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

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

34.602-89 «Техническое задание на создание автоматизированной системы» – описывает состав и содержание ТЗ, которые распространяются на автоматизированную (программноинформационную) систему в целом, в том числе:

o общесистемные требования к ПрИнС;

o требования к компонентному составу ПрИнС;

o требования к интеграции компонентов ПрИнС между собой и с другими системами; o требования к составу и содержанию работ по внедрению ПрИнС;

o …

19.201-78 «Техническое задание. Требования к содержанию и оформлению» – входит в единую систему программной документации и устанавливает порядок построения и оформления технического задания на программное изделие для ЭВМ.

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

установить общую цель создания ПрИнС, определить состав подсистем и функциональных задач;

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

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

установить общие требования к проектируемой системе;

определить перечень задач создания системы и исполнителей;

определить этапы создания системы и сроки их выполнения; провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

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

1.Все изменения в структуре ТЗ (по сравнению с ГОСТ) должны быть обязательно согласованы с заказчиком.

2.При составлении ТЗ целесообразно использовать методику «дробления и детализации». Это значит, что структура документа (разбиение на разделы и подразделы) должна быть тщательно проработана, так чтобы заинтересованное лицо могло быстро найти необходимые ему сведения относительно ПрИнС по содержанию ТЗ.

3.Сведения о функциональном назначении должны давать ответ на вопрос «для чего?», а сведения об эксплуатационном назначении – на вопрос «для кого?». Описание функционального назначения разработки должно содержать общие сведения без указания отдельных деталей.

4.Требования к программе желательно составлять на основе ГОСТов и нормативно-технической документации заказчика.

5.При составлении требований к программе целесообразно использовать метод «шаблонного построения фраз», например

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

При изложении требований к квалификации персонала: «Каждый пользователь должен обладать практическими навыками работы с графическим пользовательским интерфейсом ОС»;

и. т.п.

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

7.Требования к пользовательскому интерфейсу рекомендуется оформлять в разделе «Специальные требования».

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

Спецификация программной документации; Техническое задание; Программа и методики испытаний;

Руководства администратора и оператора 9. В раздел «Технико-экономические показатели» можно включать оценку потребности в

программном изделии и приблизительную оценку стоимости и трудоёмкости разработки.

10.	Стадии и этапы разработки обычно излагаются в форме таблицы:
Содержание		Сроки	Исполнители		Отчёт
	…	…	…		…
11.	В разделе «Порядок контроля и приёмки» рекомендуется указывать:

Какие функции программного изделия подлежат испытанию; В какие сроки и чьими силами разрабатываются программные испытания; Срок проведения испытания; Оформление испытания;

Иные условия (например, на какой технике проводятся испытания)

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

Таблица 3.1. Состав и содержание технического задания (ГОСТ 34.60289)

	№	Раздел	Содержание
	пп
	1	Общие сведения	полное наименование системы и ее условное обозначение
			шифр темы или шифр (номер) договора;
			наименование предприятий разработчика и заказчика
			системы, их реквизиты
			перечень документов, на основании которых создается
			ПрИнС
			плановые сроки начала и окончания работ

		сведения об источниках и порядке финансирования работ
		порядок оформления и предъявления заказчику результатов
		работ по созданию системы, ее частей и отдельных средств
2	Назначение и цели создания	вид автоматизируемой деятельности
	(развития) системы	перечень объектов, на которых предполагается
		использование системы
		наименования и требуемые значения технических,
		технологических, производственно-экономических и др.
		показателей объекта, которые должны быть достигнуты при
		внедрении ПрИнС
3	Характеристика объектов	краткие сведения об объекте автоматизации
	автоматизации	сведения об условиях эксплуатации и характеристиках
		окружающей среды
4	Требования к системе	Требования к системе в целом:
		требования к структуре и функционированию системы
		(перечень подсистем, уровни иерархии, степень
		централизации, способы информационного обмена, режимы
		функционирования, взаимодействие со смежными
		системами, перспективы развития системы)
		требования к персоналу (численность пользователей,
		квалификация, режим работы, порядок подготовки)
		показатели назначения (степень приспособляемости системы
		к изменениям процессов управления и значений параметров)
		требования к надежности, безопасности, эргономике,
		транспортабельности, эксплуатации, техническому
		обслуживанию и ремонту, защите и сохранности
		информации, защите от внешних воздействий, к патентной
		чистоте, по стандартизации и унификации
		Требования к функциям (по подсистемам) :
		перечень подлежащих автоматизации задач
		временной регламент реализации каждой функции
		требования к качеству реализации каждой функции, к форме
		представления выходной информации, характеристики
		точности, достоверности выдачи результатов
		перечень и критерии отказов
		Требования к видам обеспечения:
		математическому (состав и область применения мат.
		моделей и методов, типовых и разрабатываемых
		алгоритмов)
		информационному (состав, структура и организация данных,
		обмен данными между компонентами системы,
		информационная совместимость со смежными системами,
		используемые классификаторы, СУБД, контроль данных и
		ведение информационных массивов, процедуры придания
		юридической силы выходным документам)
		лингвистическому (языки программирования, языки
		взаимодействия пользователей с системой, системы
		кодирования, языки вводавывода)
		программному (независимость программных средств от
		платформы, качество программных средств и способы его
		контроля, использование фондов алгоритмов и программ)
		техническому
		метрологическому
		организационному (структура и функции эксплуатирующих
		подразделений, защита от ошибочных действий персонала)