Файл: ТРПО-лекции3.pdf

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

4.5.Условия эксплуатации. «Температура, влажность» и т.п. Напр., «система должна эксплуатироваться в нестандартных условиях (особые условия, экстремальные):». Т.е. это те технические характеристики, которые должна учитывать программа в своей работе. Этот пункт часто не пишут. Пишут его только в программно-техническом комплексе.

4.6.К составу и параметрам технических средств. Здесь студенты часто делают ошибки. Мы отрабатываем программу на своём ПК (с его конфигурацией). А потом студенты заявляют что-то вроде «прога работает на всём!!», но ведь не факт! Она и медленнее работать будет. Или не совместима с чем-то. Надо протестировать, и только протестировав, мы можем написать «система может работать под…. (и перечисляю всё то, под чем тестировал)». Обычно пишут, указывая минимальные требования и рекомендуемые. «Минимальные требования к технической платформе и операционному окружению». «Техническая платформа: (прописываю всё детально)». «Операционное окружение: (какое ПО, какие платформы, какие версии и т.п.)».

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

4.7.Требования к информационной и программной совместимости. Предположим, что-то надо оптимизировать, и делаем это через Matlab. Тогда надо указать, что мы не сами модуль делали, а использовали «сторонний». Предполагаемые методы решения, язык и среду программирования, а также другие программные средства, которые должны взаимодействовать (и каким образом) с нашими программами. С чем программа не может сосуществовать (конфликты), и т.д.

ТЗ – это язык промежуточный между профессиональными программистами и заказчиками. Поэтому не должно быть никаких профессионально-жаргонных слов. «Осуществляем back-up» – не годится. Если их не избежать, то следует создать раздел «Глоссарий», в котором требуется описать слова и их определения. Там следует указывать всю терминологию предметной области.

По поводу протоколов. Если их диктует заказчик, то «основания протоколов передачи данных такие-то, по требованию заказчика». Если заказчик выдаёт сценарий работы системы, то пишу: «по требованию заказчика, сценарий работы следующий:». А если я сам что-то определяю, то не пишу, т.к. это не исходные данные, а что-то то, чего разработать следует в ходе выполнения работы.

В этом же разделе при необходимости указывают степень защиты. Т.е. нужно ли шифрование, или нет. Каким образом будет осуществляться шифрование. Весь ли трафик шифруется, или часть. В конце привожу список стандартов, на основе которых осуществляется шифрование. А в самом начале писать: «Данное ТЗ разработано на основе ГОСТа (и полное название госта)».

4.8.Требования к программной документации. Документация бывает технологическая, научная, пользовательская и т.п. Напр., разработали ПО, передаю её, коды и инструкцию. Пользователю передаётся только пользовательская документация, инструкцию по установке, инструкцию по использованию, и описание возможных сбоев с инструкциями по их устранению. Ещё инструкцию для администратора. Все остальные вещи – это моё know-how, передавать это не стоит, за исключением тех случаев, когда они сами хотят дорабатывать его и т.д.

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

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

7.Порядок контроля и приёмки. Здесь указывать виды испытаний. В учебных проектах этот пункт писать не стоит.

ВТЗ самое главное – чёткость формулировок. Никаких лишних фраз. Все они должны звучать чётко, однозначно, грамотно. Чем отличается информационная система от пакета программ? Вот, примеры определений.

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

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

Программные комплексы – совокупность программ, совместно обеспечивающих решение задач конкретной предметной области.

Программно-технические комплексы – бывают и такие .

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

Многопользовательские программные системы – те, которые взаимодействуют по сети (в т.ч. удалённые).

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

1.Правильность – функционирование в соответствии с техническим заданием.

Есть такой процесс – «валидация», когда есть ТЗ, и их реализация. Независимый эксперт сравнивает, на сколько реализация соответствует ТЗ. Это оно и есть.

2.Универсальность – обеспечение правильной работы при любых допустимых данных и защита от неправильных данных.

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

4.Проверяемость – возможность проверки полученных результатов. Пусть, я разработал БД. И говорю: «СУБД берёт на себя то-то, контролирует то-то». Но в случае сбоя всё-таки возможны какие-то сбои целостности данных. В крупных компаниях есть такая практика – они запускают тесовые данные, благодаря которым идёт проверка целостность данных.

5.Точность результата – это обеспечение необходимой погрешности, не выше заданной.

6.Защищенность – обеспечение конфиденциальности информации. Что и где должно быть защищено, на каком уровне и т.п. По-хорошему, ещё надо это и тестировать.

7.Программная совместимость.

8.Аппаратная совместимость – возможность работы с каким-либо оборудованием.

9.Эффективность – использование минимально возможного количества вычислительных ресурсов. Этот параметр тестируется при сертификации программ. Здесь же – проверка на утечку памяти. Проверяется тестами на эффективное использование памяти.

10.Адаптивность – это этап эксплуатации, один из критериев качества. Говорит о том, на сколько разрабатываемое ПО зависит от установленного ПО и аппаратуры.

11.Повторная входимость. В случае сбоя необходимо любыми способами за минимальное время восстановить систему.

12.Реентерабельность – возможность использования несколькими процессорами параллельно. Если есть возможность что-то пустить в отдельный поток – надо пускать.

13.Предпроектное исследование предметной области. Сергей Викторович Горин часто смотрит на этот пункт. Говорят, что надо провести анкетирование. Это один из методов. Анкетирование. Составляю список вопросов (заранее). Прихожу, спрашиваю. Ответил – записываю. Не ответил – спрашиваю, у кого узнать можно.

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

Существует два варианта неопределённости на этапе анализа предметной области (в предпроектных исследованиях)

1.Неизвестны методы решения – нет информационной постановки. Поэтому часто используют «эскизный проект».

2.Неизвестная структура автоматизированных информационных процессов.

На этапе предпроектного исследования пишем модель As-Is. Что я предлагаю изменить в последовательности в бизнес-процессов, чтобы всё это дело отэффективнить.

Диаграмма Use-Case (диаграмма прецедентов)

Взять систему rational rose – см. диск с инструкцией у преподавателя.

Общие требования к проектированию:

Все участники проекта должны подчиняться единым правилам и соглашениям. К таким правилам относится:

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

2.Стандарт оформления проектной документации

3.Стандарт интерфейса пользователя.

Требования к конфигурации, к ОС, к настройкам case-системы.

Правила интеграции подсистем. Т.е. соблюдение регламента и т.п.

Стандарт оформления документации. (дописать).

Стандарт интерфейса пользователя.

1.Договариваюсь о едином оформлении экрана (т.е. пользовательского интерфейса).

2.Правило использования клавиатуры и мыши.

3.Правило оформления текста и помощи.

4.Перечень стандартных сообщений. Некоторые сообщения инициируют какую-то подсистему.

5.Правила обработки реакции пользователя. Эти правила должны быть жёстко зафиксированы.

Методология быстрой разработки приложений – RAD.

Он включает три составляющие:

1.Небольшую группу разработчиков.

2.Короткий чётко проработанный график (2-6 мес).

3.Повторяющийся цикл разработки, При котором разработчики запрашивают изменяющиеся требования и срочно вносят изменения в свои приложения.

Жизненный цикл по методологии RAD состоит из четырёх фаз (см. начало лекции 2).

Этапы RAD:

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

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

3.Фаза построения. Разработка кодов. Результатом фазы является готовая система, которую я представляю на beta-тестирование пользователям.