Техническое задание по С++ / ТЗ на АСУР с комментарии по ГОСТ.doc
«Утверждаю»
Зав. кафедрой ИПОВС
Московского института
электронной техники
__________ ( А.Э. Нестеров)
«___» __________ 2001 г.
Техническое задание
на разработку «Автоматизированной системы
управления разработками» (АСУР)
(шифр АСУР ИПОВС)
Москва, 2001
Введение
В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
Работа кафедры ИПОВС входит в новый этап. Студенты-старше-курсники будут отныне проходить производственную и преддипломную практику на кафедре, выполняя свои работы под управлением наставников-преподавателей и участвуя при этом в проводимых на кафедре НИРах и ОКРах. Такая организация работ призвана сформировать научные направления и школы, приобщить студентов к «живой» научно-исследовательской работе и принести кафедре прямой экономический эффект за счет проведения договорных работ. Возрастающая интенсивность потока информации при относительно невысоком начальном «% выхода годных» (завершенных оплаченных работ), совмещение практики студентов с основным учебным процессом в ВУЗе, большое число практикантов и научных направлений вынуждают руководство кафедры использовать современные информационные технологии для повышения эффективности управления собственными работами.
Именно с этой целью создается автоматизированная система управления.
2. Основание для разработки
В разделе «Основания для разработки» должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения.
наименование и (или) условное обозначение темы разработки.
2.1. Распоряжение заведующего кафедрой.
Наименование работы и ее шифр
Автоматизированная система управления разработками» (АСУР).
Шифр: АСУР ИПОВС.
2.3. Исполнитель: Кафедра «Информатика и программное обеспечение вычислительных систем»(ИПОВС) Московского государственного института электронной техники (МИЭТ).
3. Назначение разработки
В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
Система создается с целью систематизации, контроля и автоматизации основных этапов научно-исследовательских работ, проводимых на кафедре ИПОВС, в первую очередь, в процессе практики студентов.
4. Технические требования
Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
требования к функциональным характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
специальные требования.
4.1. Требования к функциональным характеристикам
В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.
4.1.1. Состав выполняемых функций
Создаваемая система должна обеспечивать автоматизацию основных этапов работ, проводимых на кафедре ИПОВС, в первую очередь, в процессе практики студентов, в том числе:
систематизацию данных по преподавателям, направлениям (тематике) работ и студентам-практикантам;
формирование и коррекцию коллективов по направлениям работ;
формирование и дальнейшее использование списков типовых работ по каждому из направлений (с возможностью простой коррекции этих маршрутов для конкретных приложений);
организацию контроля и прохождения работ по их направлениям с получением необходимых отчетов по датам, этапам и проч. (их перечень уточняется на этапе эскизного проектирования системы);
автоматическую выдачу напоминаний, корректирующих ускорений и т.п.;
автоматизацию делопроизводства, адресную рассылку информации заранее определенному кругу адресатов, в том числе в процессе внесения изменений в разрабатываемых проектах.
На этапе эскизного проектирования системы необходимо также:
Проработать вопросы защиты информации в системе.
Определить план мероприятий и этапность наращивания функциональных возможностей системы (от нуля до уровня ТЗ), включая разработку методических материалов и обучение персонала.
Обеспечить возможность дальнейшего наращивания функций системы (открытость для развития и методика подключения новых задач).
4.1.2. Организация входных и выходных данных
Исходные данные в систему поступают в виде писем, файлов, распечаток, договоров и ТЗ на проведение НИР или ОКР, приказов и устных распоряжений руководства кафедры.
В настоящее время планируется вести до 10 направлений работ силами 30-32 преподавателей-руководителей и 50-75 студентов-практикантов, обучающихся по специальностям 220400 и 351400.
Направления работ во многом определяются научными интересами руководителей, часто являются условными и при выполнении конкретной НИР или ОКР могут пересекаться или дополняться.
Потоки информации условно можно классифицировать как:
потоки подготовительного (маркетингового) этапа;
потоки, обеспечивающие выполнение договорных работ;
потоки архивируемых данных.
Общий текущий объем объектов контроля и сопровождения на начальном этапе работы системы определяется тем, что работа каждого студента во время практики ставится на контроль (до 75 объектов), кафедра может вести до 10 НИР/ОКР (еще 10 объектов), разного рода методические наработки и др. работы могут ставиться на контроль (еще 10-15 объектов); итого - до 100 объектов (различного содержания и наполнения).
Имеющаяся на кафедре компьютерная техника позволяет использовать для организации работ локальную сеть, а при необходимости - и выход в Интернет.
При введении системы все необходимые исходные данные должны фиксироваться в электронном виде в журнале входящей информации с отметкой о постановке на контроль и/или на исполнение по определенному маршруту. При этом система должна автоматически выполнять возможную рутинную и подготовительную работу, оставляя за руководителем право контроля и коррекции состава работ, поручаемых конкретному исполнителю, и последующего контроля прохождения работ. Исполнитель должен автоматически оповещаться о поручении и принимать непосредственное участие в разработке и согласовании плана проведения каждой конкретной работы.
Основной период использования системы - ежедневная работа, кроме того, система должна предоставлять возможность подготовки данных для представления и анализа за произвольный интервал времени (неделю, месяц и т.п.).
4.2. Требования к надежности
В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т. п.).
Для обеспечения надежности должны использоваться:
максимальное использование выверенных справочных данных, представленных в электронном виде;
отработанные стандартные технологии для работы с базами данных;
регулярное сохранение копий текущих данных в электронном виде;
сохранение необходимых копий документов и промежуточных данных в виде распечаток.
4.3. Условия эксплуатации и требования к составу и параметрам технических средств
В подразделе «Условия эксплуатации» должны быть должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т. п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.
Для работе системы должен быть выделен ответственный оператор, функции которого могут быть возложены, например, на секретаря кафедры, аспиранта или работника учебно-вспомогательного персонала.
Требования к составу и параметрам технических средств уточняются на этапе эскизного проектирования системы.
4.4. Требования к информационной и программной совместимости
В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.
При необходимости должна обеспечиваться защита информации и программ.
Система должна максимально основываться на использовании стандартных офисных пакетов MS Office - как наиболее распространенных и освоенных многими пользователями.
Выходная информация должна быть доступна с автоматизированных рабочих мест зав. кафедрой, руководителя службы контроля, секретаря и специалистов-руководителей работ, а также студентов-практикантов - с использованием действующей локальной вычислительной сети. Перечень форм уточняется на этапе эскизного проектирования системы.
4.5. Требования к транспортировке и хранению
В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места храпения, условия хранения, условия складирования, сроки хранения в различных условиях.
Не предъявляются.
4.6. Специальные требования
Не предъявляются.
5. Требования к программной документации
В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.
Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой Системы Программной Документации (ЕСПД).
6. Технико-экономические показатели
В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
Эффективность системы определяется упорядочением и ускорением прохождения документов, снижением нагрузки на высоко квалифицированных специалистов за счет автоматизации решения рутинных задач, улучшения имиджа кафедры, наработки методики проведения собственных НИР и ОКР с использованием современных информационных технологий.
7. Стадии и этапы разработки
В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.
В течение августа 2001 г. должны быть проведены следующие работы:
заведены базовые сведения по преподавателям, направлениям (тематике) работ и студентам-практикантам;
разработан программный модуль для автоматизированного формирования и коррекции коллективов по направлениям работ;
разработана методика формирования и дальнейшего использование списков типовых работ по каждому из направлений (с возможностью простой коррекции этих маршрутов для конкретных приложений);
разработана методика организации контроля и прохождения работ по их направлениям с получением необходимых отчетов по датам, этапам и проч. с автоматической выдачей напоминаний, корректирующих ускорений и т.п.;
сформирован список типовых работ по работе студентов во время производственной практики, а также при проведении программных разработок с учетом требований отечественных и международных стандартов;
подготовлен семинар для преподавателей и студентов-практикантов по методике проведения практики и контроля работ.
Дальнейшие работы определяются на этапе эскизного проектирования системы.
8. Порядок контроля и приемки
В разделе «Порядок контроля и приемки» должны быть указаны виды испытании и общие требования к приемке работы.
Определяются на этапе эскизного проектирования системы с учетом согласованной этапности введения отдельных подсистем.
Доцент В.М. Трояновский