Этапы разработки программного обеспечения при структурном подходе к программированию

Автор: Пользователь скрыл имя, 17 Февраля 2012 в 13:52, лабораторная работа

Краткое описание

Цель работы: ознакомиться с правилами написания технического задания.
Подготовка к лабораторной работе
Ознакомиться с лекционным материалом по теме «Модели ЖЦ ПО. Этапы ЖЦ в соответствии с ГОСТ 19.102-77. Постановка задачи» учебной дисциплины «Разработка и стандартизация ПС и ИТ».

Файлы: 1 файл

ЛАБОРАТОРНАЯ РАБОТА№1 РСПСиИТ.doc

— 219.00 Кб (Скачать)

ЛАБОРАТОРНАЯ РАБОТА № 1

Этапы разработки программного обеспечения при структурном подходе к программированию. Стадия «Техническое задание»

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

Подготовка к лабораторной работе

Ознакомиться с лекционным материалом по теме «Модели ЖЦ ПО. Этапы ЖЦ в соответствии с ГОСТ 19.102-77. Постановка задачи» учебной дисциплины «Разработка и стандартизация ПС и ИТ».

1.        Изучить соответствующие разделы в изданиях [1 - 3].

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

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

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

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

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

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

1. Общие положения

1.1.              Техническое задание оформляют в соответствии с ГОСТ 19.106—78 на листах формата А4 и A3 по ГОСТ 2.301—68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

1.2.              Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104—78. Информационную часть (аннота­цию и содержание), лист регистрации изменений допускается в документ не включать.

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

1.4.              Техническое задание должно содержать следующие разделы:

•введение;

•наименование и область применения;

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

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

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

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

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

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

приложения.

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

2. Содержание разделов

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

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

2.3.              В разделе «Основание для разработки» должны быть указаны:

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

• организация, утвердившая этот документ, и дата его утверждения;

• наименование и (или) условное обозначение темы разработки.

2.4.              В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

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

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

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

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

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

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

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

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

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

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

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

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

2.5.4.        В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их технических характеристик.

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

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

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

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

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

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

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

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

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

другие источники разработки.

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

Примеры разработки технического задания приведены в приложениях Б и В.

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

1.                   Разработать техническое задание на программный продукт согласно своему варианту (см. варианты в приложении А)

2.                   Оформить работу в соответствии с ГОСТ 19.106-78. При оформлении использовать MS Office.

3.                   Сдать и защитить работу.

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен быть оформлен на основании СТП и состоять из следующих структурных элементов:

  1. титульный лист;
  2. текстовая часть;
  3. приложение: разработанное технического задания на программный продукт.

Текстовая часть отчета должна включать пункты:

       условие задачи;

       порядок выполнения.

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

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

1.                   Дайте понятие модели жизненного цикла ПО.

2.                   Приведите этапы разработки программного обеспечения.

3.       Что включает в себя постановка задачи и предпроектные исследования?

4.       Перечислите функциональные и эксплуатационные требования к программному продукту.

5.       Перечислите правила разработки технического задания.

6.                   Назовите основные разделы технического задания.


Список литературы

1.       Бедрина С.Л., Разработка и стандартизация программного обеспечения. – Владивосток: Издательство ВГУЭС, 2006.

2.       Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств. – М: Финансы и статистика, 2003.

3.        ГОСТ 19.102-77 ЕСПД. Стадии разработки


Приложение А

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

Лабораторные работы № 1—5 выполняются для одного и того же варианта.

1.     Разработать программный модуль «Учет успеваемости студентов». Программный модуль предназначен для оперативного учета успеваемости студентов в сессию деканом, заместителями декана и сотрудниками деканата. Сведения об успеваемости студентов должны храниться в течение всего срока их обучения и использоваться при составлении справок о прослушанных курсах и приложений к диплому.

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

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

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

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

6.    Разработать приложение Windows «Калькулятор». Приложение предназначено для любых пользователей и должно содержать все арифметические операции (с соблюдением приоритетов) и желательно (но не обязательно) несколько математических функций.

7.    Разработать программный модуль «Кафедра», содержащий сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль предназначен для использования сотрудниками отдела кадров и деканата.

8.    Разработать программный модуль «Лаборатория», содержащий сведения о сотрудниках лаборатории (ФИО, пол, возраст, семейное положение, наличие детей, должность, ученая степень). Модуль предназначен для использования сотрудниками профкома и отдела кадров.

9.    Разработать программный модуль «Химчистка». При записи на обслуживание заполняется заявка, в которой указываются ФИО владельца, описание изделия, вид услуги, дата приема заказа и стоимость услуги. После выполнения работ распечатывается квитанция.

10. Разработать программный модуль «Учет нарушений правил дорожного движения». Для каждой автомашины (и ее владельца) в базе хранится список нарушений. Для каждого нарушения фиксируется дата, время, вид нарушения и размер штрафа. При оплате всех штрафов машина удаляется из базы.

11.   Разработать программный модуль «Картотека автомагазина», предназначенный для использования работниками агентства. В базе содержатся сведения об автомобилях (марка, объем двигателя, дата выпуска и др.). При поступлении заявки на покупку производится поиск подходящего варианта. Если такого нет, клиент заносится в клиентскую базу и оповещается, когда вариант появляется.

12.   Разработать программный модуль «Картотека абонентов АТС». Картотека содержит сведения о телефонах и их владельцах. Фиксирует задолженности по оплате (абонентской и повременной). Считается, что повременная оплата местных телефонных разговоров уже введена.

13.   Разработать программный модуль «Автокасса», содержащий сведения о наличии свободных мест на автобусные маршруты. В базе должны содержаться сведения о номере рейса, маршруте, водителе, типе автобуса, дате и времени отправления, а также стоимости билетов. При поступлении заявки на билеты программа производит поиск подходящего рейса.

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

15.   Разработать программный модуль «Автостоянка». В программе содержится информация о марке автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др.

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

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


Приложение Б

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


1. Введение

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

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

2.1.              Программа разрабатывается  на основе учебного плана кафедры «Информатика и программное обеспечение вычислительных систем».

2.2.              Наименование работы:

«Программа сортировки одномерного массива».

2.3.              Исполнитель: компания BcstSoft.

2.4.              Соисполнители: ист.

3. Назначение

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

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

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

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

ввод размера массива и самого массива;

хранение массива и памяти;

выбор метола сортировки;

вывод текстового описании метода сортировки;

вывод результата сортировки.

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

размер массива, заданный целым числом;

массив.

4.1.3.        Организация входных и выходных данных.

Входные данные поступают с клавиатуры.

Выходные данные отображаются на экране и при необходимости выводятся на печать.

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

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

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

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

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

тип процессора              Pentium и выше;

объем оперативного запоминающего устройства              32 Мб и более;

объем свободного места на жестком диске              40 Мб.

Рекомендуемая конфигурация:

тип процессора              Pentium II 400;

объем оперативного запоминающего устройства              128 Мб;

объем свободного места на жестком диске              60 Мб.

4.4.              Требования к программной совместимости.
Программа должна работать под управлением семейства операционных систем Win 32 (Windows 95/98/2000/МЕ/ХР и т. п.).

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

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

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

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

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

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


Приложение В

Пример 2. Разработать техническое задание на разработку «Модуля автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского ин­ститута».

 


1. Введение

Работа выполняется в рамках проекта «Автоматизированная система оперативно-диспетчерского управления электротеплоснабжением корпусов Московского института».

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

2.1.              Основанием для данной работы служит договор № 1234 от 10 марта 2003 г.

2.2.              Наименование работы:

«Модуль автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского института».

2.3.              Исполнители: ОАО «Лаборатория создания программного обеспечения».

2.4.              Соисполнители: нет.

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

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

4.              Технические требования

4.1. Требования к функциональным характеристикам. 4.1.1. Состав выполняемых функций. Разрабатываемое ПО должно обеспечивать:

сбор и анализ информации о расходовании тепла, горячей и холодной воды по данным теплосчетчиков SA-94 на всех тепловых выходах;

сбор и анализ информации с устройств управления системами воздушного отопления и кондиционирования типа РТ1 и РТ2 (разработки кафедры СММЭ и ТЦ);

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

выдачу рекомендаций по дальнейшей работе;

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

визуализацию информации по расходу теплоносителя:

                   текущую, аналогично показаниям счетчиков;

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

                   суточный расход — для информации за месяц.

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

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

В конце отчетного периода система должна архивировать данные.

4.1.2. Организация входных и выходных данных.

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

Основной режим использования системы — ежедневная работа.

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

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

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

Для работы системы должен быть выделен ответственный оператор.

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

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

Программа должна работать на платформах Windows 98/ NT/2000.


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

Программа поставляется на лазерном носителе информации.

Программная документация поставляется в электронном и печатном виде.

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

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

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

язык программирования — по выбору исполнителя, должен обеспечивать возможность интеграции программного обеспечения с некоторыми видами периферийного обору­дования (например, счетчик SA-94 и т. п.).

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

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

6. Технико-экономические показатели

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

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

После передачи Исполнителем отдельного функционального модуля программы Заказчику последний имеет право тестиро­вать модуль в течение 7 дней. После тестирования Заказчик должен принять работу по данному этапу или в письменном виде изложить причину отказа принятия. В случае обоснованного отказа Исполнитель обязуется доработать модуль.

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