«Технология разработки программного обеспечения»

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

 

Санкт-Петербургский государственный университет аэрокосмического

Приборостроения

 

Кафедра компьютерной математики и программирования (№ 43)

 

 

«Технология разработки программного обеспечения»

 

Методические рекомендации к выполнению курсовой работы

 

Санкт-Петербург

2006 г.

 

Введение

 

 

Предметом дисциплины «Технология разработки программного обеспечения» является модели и методы проектирования и разработки программного обеспечения.

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

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

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

1. PowerDesigner 6.0.

2. Rational Rose 2000.

3. Доступную среду программирования.

 

Методические рекомендации к выполнению курсовой работы

  Задание на КР: Реализовать проект по созданию программной системы для заданной (выбранной) предметной области. Реализация…  

Варианты заданий

Варианты задания приведены в таблице 1.

Таблица 1

№ вар.	Предметная область
	Расписание движения поездов
	Расписание движения самолетов
	Заказ товаров почтой
	Проведение вступительных экзаменов
	Обслуживание читателей в библиотеке
	Служба занятости
	Регистрация больных в поликлинике
	Регистрация участников конференции
	Книга почтой
	Гостиничный комплекс
	Деканат
	Прокат автомобилей
	Деловые контакты фирмы
	Подписка на газеты и журналы
	Продажа-покупка акций
	Обменный пункт валют
	Туристическое агентство
	Отдел сбыта предприятия
	Фильмотека
	Складское хозяйство предприятия
	Репертуар театров города
	Выставочные залы города
	Экскурсионное бюро
	Маршруты городского транспорта

Последовательность выполнения курсового проекта

1. Ознакомиться с заданием на курсовое проектирование, выбрать предметную область. 2. Собрать и проанализировать информацию из печатных, электронных источников… 3. Разработать Техническое задание на программную систему.

Обязательные требования.

2. Программная система должна состоять из БД и прикладной(ых) программ. Прикладные программы должны реализовывать функции обработки данных, хранимых… 3. Программная документация должна быть оформлена в едином стиле, в том числе…  

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

1. Задание на курсовой проект.

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

3. Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств.

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

5. Техническое задание за реализацию автоматизируемых функций программного проекта.

6. Описание Плана реализации проекта.

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

8. Заключение

9. Список используемых источников (книги, журналы, сайты интернет).

 

Приложение1

 

Пример оформления пункта 3 пояснительной записки.

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

Обзор методологий разработки программного обеспечения

Категории методологий

В мире существует довольно много типовых процессов производства программного обеспечения. ISO9001, ISO12207, ISO15504, CMM (Capability Maturity… Под методологией понимается набор методов, практик, метрик и правил,… облегчить процедуру введения новых людей в курс процесса производства;

Описание некоторых методологий разработки ПО

Согласно материалу предыдущего параграфа, методологии разработки программного обеспечения условно делятся на три категории: легкие методологии,… Наиболее известными методологиями первой категории являются: XP (eXtreme Programming)

XP - eXtreme Programming

…………………………….. На сегодняшний день ХР широко распространилась и заслужила признание - все…  

SCRUM

Методология SCRUM предназначена для маленьких команд.

Проект начинается с создания "резерва свойств системы" (backlog). Резерв свойств - это набор функций системы, которые необходимо реализовать. Сами функции могут быть описаны с помощью пользовательских сценариев или более традиционных требований. Контроль над резервом имеет только один человек, обычно это заказчик системы. Резерв постоянно изменяется, функции дополняются и сортируются по приоритетам. После того, как резерв будет немного наполнен, начинается первая итерация. Весь проект делится на итерации (в SCRUM итерацию называют спринтом) длительностью в 30 дней. Правда, длительность итерации можно варьировать, это зависит от конкретного проекта. Для одной итерации выбирают функции, которые будут в ней реализованы. Самое важное условие - неизменность выбранных функций во время одной итерации. Это позволяет разбить весь большой проект с изменяющимися требованиями на некоторое количество фиксированных небольших итераций со стабильными требованиями.

…………………………..

 

Crystal Clear

 

CMM (Capability Maturity Model)

 

RUP (Rational Unified Process)

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

Выбор и обоснование средств разработки и аппаратных средств

Одним из этапов развития архитектуры информационных систем было появление сетевых версий вышеупомянутых настольных СУБД, позволяющих осуществлять… Такой подход сочетал в себе как удобства персонализации пользовательской среды… Недостатки использования сетевых версий настольных СУБД обычно начинают проявляться в процессе длительной эксплуатации…

Выбор и обоснование использование MS SQL Server 2000 в качестве серверной СУБД

Для выбора СУБД сравним их по следующим параметрам: производительность, цена, доступность, удобство использования, возможности. При выборе СУБД… На сайте www.tpc.org опубликованы данные TPC тестов и сравнение цен серверов.… Однако следует отметить, что подобного рода тесты не могут дать однозначного ответа на вопрос, какая из СУБД будет…

Рис. Процент использования СУБД

 

 

Таблица. Сравнительные характеристики СУБД.

Сервер	Достоинства	Недостатки
IBM DB2 Universal Database	Самый мощный язык запросов; Лучший оптимизатор; Возможность писать функции на других языках.	Высокая стоимость; Малая распространенность; Сложность Администрирования.
Oracle Database	Великое множество дополнительных возможностей; Кросс-платформенный сервер; Хорошее быстродействие.	Очень высокая стоимость; сервера и поддержки; Не во всех версиях поставляется средство администрирования СУБД; Сложность Администрирования.
Microsoft SQL Server	Самое высокое быстродействие; Самая большая распространенность; Относительно невысокая стоимость; Достаточно прост в администрировании; Быстро развивающийся продукт, уже вплотную приближающийся к своим более развитым конкурентам.	Существует только для одной платформы (Win32); Меньшие возможности по сравнению с Oracle и DB2.

 

 

В таблице приведены основные достоинства и недостатки рассматриваемых СУБД. Для разрабатываемой системы будет использоваться СУБД MS SQL 2000. Данный выбор обосновывается широким распространением данной системы, высокой производительностью при низкой стоимости сервера и простотой поддержки системы. Кроме того, серверный компьютер будет работать под управлением операционной системы из семейства Windows NT, что обеспечивает еще одно преимущество MS SQL Server 2000, т.к. именно данная СУБД наилучшим образом оптимизирована для операционной системы Windows.

 

Выбор и обоснование использования MS Visual Studio и MS Visual C++, в качестве средств разработки.

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

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

На сегодняшний день существует большое разнообразие и изобилие средств разработки. Рассмотрим основные достоинства и недостатки трех из них, как наи – Delphi, С++ Builder и MS Visual C++/Visual Studio.

Delphi

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

Достоинства:

………………………

Недостатки

………………………

C++ Builder

Некий "гибрид" Delphi и C++, о чем говорит хотя бы то, что C++ Builder использует ту же библиотеку VCL, что и Delphi, причем написанную на Delphi. В свете этого логичной выглядит совместимость C++ Builder с Delphi на уровне компонентов и исходного кода.

Достоинства:

…………………..

Недостатки:

……………………

 

MS Visual C++

Продукт Microsoft Visual C++ .NET – мощное средство разработки, позволяющее создавать программы на базе Microsoft Windows, с поддержкой технологии Microsoft .NET, динамические web-приложения и web-службы XML с использованием языка программирования C++. Библиотека классов MFC, входящая в состав Visual C++ позволяет существенно облегчить создание графического интерфейса приложений. Однако от программистов VC++ требуется гораздо большая квалификация, нежели от программистов Delphi, т.к. MFC, несмотря на всю свою «мощность», является всего лишь тонкой «оберткой» над WinApi, и поэтому при написании приложений многое приходится делать вручную. С одной стороны это является минусом, т.к. сильно снижается скорость разработки. С другой стороны это дает более широкие возможности и гибкость при реализации крупных проектов и позволяет добиться их максимальной производительности.

Преимущества:

…………………………

Недостатки:

…………………………

 

Выбор и обоснование аппаратных средств

Microsoft Windows 2000 (Server, Advanced Server) MS SQL Server 2000 Enterprise  

Описание технологического процесса.

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

СОДЕРЖАНИЕ РАБОТ ПО ФАЗАМ, СТАДИЯМ И ЭТАПАМ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ

 

Таблица Б.1 — Фаза «Анализ». Стадия «Формирование требований»

Наименование этапа	Содержание работ
Б.1.1 Анализ потребности в ПС	Анализ состава функций и тактико-технических требований (ТТТ) к системе, в которой предполагается применение ПС
Б.1.2 Разработка требований к ПС	Разработка общесистемных требований к ПС, в том числе: - определение перечня задач; - спецификация входных и выходных данных и диапазонов их изменения; - определение источников информации для каждого объекта автоматизации; - описание алгоритмов взаимодействия с внешними системами; - описание алгоритма технологического и информационно-логического взаимодействия должностных лиц. Разработка требований к техническим средствам, в том числе к: - составу и параметрам вычислительных средств; - ограничениям на вычислительные средства в принятой операционной среде. Разработка требований к математическому, программному и информационному обеспечению, в том числе к: - созданию и обоснованию алгоритмов и расчетных методик; - модульности и гибкости математического обеспечения; - полноте реализации; - логической корректности; - проверенности; - защищенности; - надежности, точности и времени решения задач;
	- ресурсам памяти; - языкам программирования; - средствам программирования и использованию перспективных технологий программирования; - порядку испытаний программ и сдачи их в эксплуатацию; - использованию сервисных (стандартных) сертифицированных программ; - системе классификации и кодирования информации, принципам ее формализации; - носителям информации; - хранению, обновлению, контролю и выдаче информации; - организации взаимообмена информацией между элементами системы. Разработка специальных требований к: - секретности; - условиям эксплуатации; - транспортированию ПС и т.п. Разработка требований к сертификации ПС. Согласование и утверждение ТТЗ

 

Таблица Б.2 — Фаза «Проектирование». Стадия «Разработка концепции»

 

Наименование этапа	Содержание работ
Б.2.1 Обоснование необходимос­ти разработки ПС	Постановка задач, определение функций. Исследование вариантов автоматизации системы. Анализ аналогов ПС. Выбор и обоснование критериев эффективности и качества разрабатываемого ПС. Предварительная декомпозиция ПС на комплексы программ и компоненты. Обоснование необходимости научно-исследовательских работ. Анализ требований к ПС на реализуемость и непротиворечивость. Разработка дополнительных требований, уточнений и ограничений на ПС в части: - мобильности; - надежности; - безопасности; - вычислительных ресурсов; - условий использования; - операционной среды; - программной документации; - порядка внесения изменений; - взаимодействия с внешними программными комплексами и между компонентами ПС; - взаимодействия с аппаратными средствами комплексов; - порядка, видов и сроков испытаний и приемки ПС; - критериев, методов и средство оценки качества ПС
Б.2.2 Научно-исследовательские работы	Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленных задач

 

Таблица Б.З — Фаза «Разработка». Стадия «Техническое задание»

Наименование этапа	Содержание работ
Б.3.1 Разработка ТЗ на ПС	Формализация требований к ПС. Определение стадий, этапов и сроков разработки ПС. Разработка программной документации на ПС. Разработка технико-экономического обоснования разработки ПС. Оформление ТЗ на ПС. Согласование и утверждение ТЗ на ПС

 

Таблица Б.4 — Фаза «Разработка». Стадия «Эскизный проект»

Наименование этапа	Содержание работ
Б.4.1 Функциональный анализ	Определение оптимального соотношения аппаратных и программных способов реализации автоматизированных функций системы. Уточнение и анализ функций, реализуемых ПС: - алгоритмы решения задач; - интерфейсы (внешние, пользовательские, межкомплексные); - способы контроля функционирования; - способы реализации требований надежности и специальных требований. Уточнение декомпозиции ПС на комплексы программ и компоненты. Анализ и опробование аналогов ПС из патентных источников. Моделирование функций и характеристик ПС. Разработка функциональной архитектуры ПС
Б.4.2 Разработка требований к конфигурации вычислительного комплекса	Уточнение требований к вычислительным ресурсам. Разработка требований к конфигурации вычислительных средств и сопроцессорным устройствам. Разработка ЧТЗ на компоненты вычислительного комплекса. Выбор языков программирования
Б.4.3 Планирование разработки	Ориентировочные расчеты трудозатрат, времени и стоимости разработки ПС. Оценка реальных сроков разработки ПС и ресурсов. Формирование укрупненного сквозного графика разработки ПС. Выбор и обоснование основных концепций технологии разработки ПС и состава технологического стенда на базе серийной вычислительной техники. Разработка ЧТЗ на компоненты ПС. Создание кооперации организаций-исполнителей. Разработка, испытание, передача в опытную эксплуатацию и сопровождение отдельных компонентов ПС. Разработка руководящих указаний по проектированию компонентов ПС. Уточнение ТЗ на разработку ПС по стадиям и этапам работ. Создание базы данных программного проекта для автоматизированного управления и контроля хода разработки ПС
Б.4.4 Выпуск эскизного проекта ПС	Составление пояснительной записки эскизного проекта ПС. Согласование и утверждение эскизного проекта ПС

 

Таблица Б.5 — Фаза «Разработка». Стадия «Технический проект»

Наименование этапа	Содержание работ
Б.5.1 Технологическая подготовка разработки ПС	Уточнение технологии проектирования разработки, докумен­тирования и испытаний ПС, согласование с организациями-исполнителями. Расчет ресурсов и производительности технологической линии разработки программ (ТЛПП). Выбор средств автоматизации проектирования, программирования, тестирования, документирования. Доукомплектация ТЛПП техническими и программными средствами. Настройка инструментальных средств разработки ПС. Разработка ЧТЗ на средства автоматизации испытаний ПС, тренажеры и обучающие средства
Б.5.2 Проектирование ПС	Проверка на полноту, непротиворечивость и завершенность описания ПС. Декомпозиция ПС на модули и другие компоненты. Уточнение взаимодействия программных комплексов и компонентов. Разработка протоколов обмена со смежными системами. Разработка структур данных, входных и выходных форм документов, методов организации доступа и способов кодирования и контроля. Разработка внешних связей компонентов ПС. Детализация требований к ресурсам, параметрам используемых; вычислительных средств. Контроль внешних связей и протоколов обмена. Оценка качества проекта ПС. Уточнение требований к функционированию компонентов ПС. Разработка, согласование и уточнение ТЗ на программирование компонентов ПС
Б.5.3 Детальное проектирование ПС и структур данных	Детальная разработка структур данных, выбор программных средств их ведения. Разработка требований к функционированию компонентов ПС с учетом технических характеристик. Разработка прототипа ПС и имитатора модели внешней среды, Испытание прототипа ПС. Корректировка прототипа ПС. Уточнение графика разработки ПС. Разработка, испытание, передача в опытную эксплуатацию и сопровождение отдельных компонентов ПС
Б.5.4 Создание технологических стендов для отладки и испытаний ПС	Уточнение требований к вычислительным ресурсам системы. Разработка уточненных требований к составу и срокам готовности стендов
Б.5.5 Выпуск технического проек­та ПС	Разработка пояснительной записки к техническому проекту ПС. Согласование и утверждение технического проекта

 

Таблица Б.6 — Фаза «Разработка». Стадия «Рабочая документация»

Наименование этапа	Содержание работ
Б.6.1 Разработка программ и программной документации ПС	Разработка детального графика кодирования, компоновки, документирования и испытания программ. Технологическая подготовка стадии «Рабочая документация». Разработка средств тестирования и программ-имитаторов для автономной и комплексной отладки ПС. Разработка машинных алгоритмов модулей. Создание программы (кодирование, трансляция). Разработка тестов модулей. Тестирование модулей. Автономная отладка ПС. Уточнение функций модулей. Документирование программ компонентов. Оценка качества программ компонентов
Б. 6.2 Комплексная отладка ПС	Разработка детального (сетевого) графика комплексной отладки ПС. Настройка ТЛПП. Компоновка комплексов программ. Подготовка тестовых примеров. Отладка комплексов программ в статическом режиме. Проверка готовности технологического стенда отладки и испытаний ПС. Отладка комплексов программ в реальном масштабе времени. Оценка качества комплексов программ. Выпуск программной документации на комплексы программ. Разработка технических условий на компоненты ПС
Б.6.3 Тестирование комплексов программ	Разработка методики и графика тестирования. Подготовка тестовых примеров и исходных данных с участием заказчика. Тестирование комплексов программ. Ведение журнала тестирования. Анализ результатов тестирования программных модулей. Устранение ошибок, корректировка программ и документации на ПС по результатам тестирования. Оценка качества комплексов программ

 

Таблица Б.7 — Фаза «Разработка». Стадия «Ввод в действие»

Наименование этапа	Содержание работ
Б.7.1 Предварительные испытания ПС	Разработка программы и методики испытаний ПС. Комплектование системы носителями и программной документацией. Подготовка совместно с заказчиком контрольных примеров. Проведение совместно с заказчиком испытаний в соответствии с программой и методикой. Ведение журнала испытаний ПС. Доработка ПС по результатам испытаний. Уточнение технических требований и требований к функционированию ПС. Корректировка программной документации. Подготовка заключения о готовности ПС к работе в системе. Обучение должностных лиц системы работе с ПС при испытаниях. Передача ПС и программной документации головному разработчику
Б.7.2 Приемочные испытания ПС	Участие в согласовании программы и методики испытаний и графика проведения испытаний. Сопровождение испытаний. Формирование технических требований на модернизацию ПС. Подготовка заключения о функционировании ПС при приемочных испытаниях системы.
Б.7.3 Предъявление ПС	Корректировка программы и программной документации по результатам приемочных испытаний.

 

Таблица Б.8 — Фаза «Применение». Стадия «Производство»

Наименование этапа	Содержание работ
Б.8.1 Постановка ПС на производство	Передача программ на носителях данных и программных документов на предприятие - изготовитель программного продукта. Подготовка производства для изготовления программных изделий и программной документации. Освоение производства ПС. Уведомление службы сопровождения о рекомендациях пользователе. Сопровождение производства ПС.
Б.8.2 Изготовление ПС	Подготовка исходных параметров для настройки версий ПС. Генерация данных для версий ПС. Компоновка версий ПС. Формирование программного изделия версии ПС. Выпуск комплекта эксплуатационной документации для версии ПС.
Б.8.3 Контроль и приемка ПС	Выходной контроль постоянной части ПС по составу и содержанию. Выходной контроль ПИ. Тиражирование ПИ и комплекта эксплуатационной документации для комплектования поставки. Контроль копий на соответствие техническим условиям на ПС. Приемка ПИ и комплекта эксплуатационной документации отделом технического контроля. Сертификация ПС
Б.8.4 Поставка ПС потребителю	Отправление ПС потребителю. Приемка ПС потребителем. Сохранение подлинников.

 

Таблица Б. 9 — Фаза «Применение». Стадия «Сопровождение»

Наименование этапа	Содержание работ
Б.9.1 Организация сопровождения ПС	Приемка ПС на сопровождение. Прогнозирование трудоемкости сопровождения ПС. Разработка технологии сопровождения ПС.
Б.9.2 Модернизация ПС	Анализ заявок на модификацию ПС. Планирование работ по модификации компонентов ПС или их разработка. Проведение модификации компонентов ПС в соответствии с ЧТЗ. Выпуск извещений об изменении ПС. Внесение изменений в программную документацию.
Б.9.3 Анализ функционирования ПО	Учет и классификация ошибок в ПС. Учет трудоемкости модификации ПС. Разработка предложений о развитии и совершенствовании ПС.

 

Таблица Б. 10 — Фаза «Применение». Стадия «Эксплуатация»

Наименование этапа	Содержание работ
Б.10.1 Опытная (эксперименталь­ная) эксплуатация ПС	Ввод ПС в опытную эксплуатацию на объекте заказчика. Сбор данных о функционировании ПС в составе системы. Устранение ошибок в ПС и доработка ПС разработчиками.
Б.10.2 Функционирование ПС в составе системы	Ввод ПС в штатную эксплуатацию. Сбор данных о функционировании ПС. Формирование пользователем технических требований на модернизацию ПС (через службу сопровождения). Внесение изменений в ПС.
Б. 10.3 Подготовка к снятию ПС с эксплуатации	Обоснование целесообразности снятия ПС с эксплуатации. Подготовка и утверждение документа о снятии ПС с эксплуатации. Организация хранения документации на ПС и копий ПС на машинных носителях
Б.10.4 Прекращение эксплуатации ПС	Снятие ПС с эксплуатации. Списание ПС.

 

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

Еще одним вариантом построения технологического процесса является вариант, в основу которого положен международный стандарт ISO 12207 (стандарты ГОСТ Р ИСОМЭК ТО 15271-2002 «Руководство по применению ГОСТ Р ИСОМЭК 12207», ГОСТ Р ИСОМЭК ТО 16326-2002 «Руководство по применению ГОСТ Р ИСОМЭК 12207 при управлении проектом», ГОСТ Р ИСОМЭК 15910-2002 «Процесс создания документации пользователя программного средства» и др.).

 

5. Пример оформления Технического задания

 

 

СОГЛАСОВАНО     «____» _____________ 200_ г.

УТВЕРЖДАЮ     «____» _____________ 200_ г.

 

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

на разработку текстового редактора “Блокнот”

 

СОДЕРЖАНИЕ

Лист

1. Введение................................................................................................... 16

2. Основание для разработки............................................................. 16

2.1. Основание для разработки................................................................... 16

2.2. Исполнитель и заказчик........................................................................ 16

2.3. Наименование........................................................................................ 16

3. Назначение разработки.................................................................... 16

4. Требования к программе или программному изделию. 17

4.1. Требования к составу............................................................................ 17

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

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

4.4. Условия эксплуатации.......................................................................... 18

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

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

4.7. Требования к маркировке и упаковке.................................................. 20

4.8. Требования к транспортировке и хранению....................................... 20

4.9. Специальные требования...................................................................... 21

5. Требования к программной документации......................... 21

5.1. Требования к составу документации................................................... 21

5.2. Требования к оформлению документации.......................................... 21

6. Технико-экономические требования...................................... 22

7. Стадии и этапы разработки........................................................... 22

8. Порядок контроля и приемки........................................................ 22

9. Порядок внесения изменений в техническое задание.. 22

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ........................................................................... 24

 

Введение

Настоящее техническое задание, оформленное в соответствии с ГОСТ 19.201-78, содержит требования к текстовому редактору, предназначенного для просмотра и редактирования текстовых файлов на ПЭВМ.

2. Основание для разработки

 

2.1 Основание для разработки

Основанием для разработки текстового редактора является…

2.2 Исполнитель и заказчик

Заказчиком разработки, выполняемой по настоящему ТЗ, является …

Исполнителем разработки, выполняемой по настоящему ТЗ, является …

2.3 Наименование

Программе, разрабатываемой по настоящему ТЗ, присваивается наименование: "Текстовый редактор "Блокнот", в дальнейшем по тексту именуемая ТР.

3. Назначение разработки

 

3.1 ТР предназначен для выполнения следующих действий с текстовыми файлами на ПЭВМ:

- создания;

- просмотра;

- редактирования;

- вывода на печать.

4. Требования к программе или программному изделию

Требования к составу

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

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

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

- создавать текстовый файл в кодировке ANSI; - открывать для просмотра или редактирования текстовый файл в кодировке… - редактировать созданный или открытый текстовый файл;

Требования к редактированию текстового файла

- вводить символы в кодировке ANSI в позицию, отмеченную курсором; - осуществлять перемещение курсора ввода с помощью клавиатуры или манипулятора… - выделять с помощью клавиатуры или манипулятора типа “мышь” один и более символов, расположенных рядом, а также…

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

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

Время восстановления ТР после отказа не должна превышать 0,5 часа.

ТР в составе ПО ПЭВМ, должен выполнять функциональные задачи по назначению в течении всего срока эксплуатации ПЭВМ.

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

ТР должен функционировать в соответствии с заданными в настоящем ТЗ требованиями, в составе ПО ПЭВМ, при эксплуатации ПЭВМ.

4.4.2 Условия эксплуатации должны соответствовать условиям эксплуатации ПЭВМ, требования к которым предъявляются в эксплуатационной документации ПЭВМ или ее составных частей.

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

ТР должен функционировать на ПЭВМ со следующими характеристиками

- процессор не хуже Pentium III 500МГц;

- объем ОЗУ не менее 64 Мб;

- НГМД 3,5 (1,44 Мб);

- НЖМД не менее 10 Гб;

- графический адаптер не хуже SVGA 8 Мб;

- монитор не хуже SVGA 0.26, 17 дюймов;

- сетевая плата, совместимая с Ethernet;

- манипулятор типа “мышь”;

- лазерный принтер формата А4.

Штатным носителем ТР является НЖМД ПЭВМ. Технологическим носителем ТР является НГМД.

Объем ОЗУ, используемого ТР при своем функционировании, не должен превышать 64 кб.

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

В качестве языков программирования ТР должен быть использован язык программирования Си.

ТР должен функционировать на ПЭВМ с одной из операционных систем MS Windows 95, MS Windows 98, MS Windows NT, MS Windows 2000, MS Windows XP.

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

Для реализации интерфейса между ТР и другими программами из состава ПО ПЭВМ должны использоваться средства буфера обмена операционной системы.

Требования к маркировке и упаковке

Маркировка НГМД с ТР должна проводиться в соответствии с требованиями ГОСТ 19.103-77 ЕСПД.

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

Требования к транспортировке

4.8.1.1 ТР должен транспортироваться:

- в составе ПЭВМ, записанный на НЖМД ПЭВМ;

- на НГМД.

Условия транспортировки ТР в составе ПЭВМ должны соответствовать условиям транспортировки ПЭВМ, требования к которым предъявляются в эксплуатационной документации ПЭВМ или ее составных частей.

Условия транспортировки ТР на НГМД должны соответствовать условиям транспортировки НГМД, требования к которым предъявляются в эксплуатационной документации НГМД.

Требования по хранению

4.8.2.1 ТР должен храниться:

- в составе ПЭВМ, записанный на НЖМД ПЭВМ;

- на НГМД.

Условия хранения ТР в составе ПЭВМ должны соответствовать условиям хранения ПЭВМ, требования к которым предъявляются в эксплуатационной документации ПЭВМ или ее составных частей.

Условия хранения ТР на НГМД должны соответствовать условиям хранения НГМД, требования к которым предъявляются в эксплуатационной документации НГМД.

Специальные требования

Требования не предъявляются.

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

Требования к составу документации

Состав документации определяется Исполнителем на этапе разработки перечнем разрабатываемых документов и согласовывается с Заказчиком.

5.1.2 В комплект документации в обязательном порядке должны входить:

- спецификация;

- текст программы;

- руководство оператора;

- загрузочные модули;

- программа и методика испытаний.

Требования к оформлению документации

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