О чем речь. Этапы разработки ИС. Обследование деятельности предприятия (объекта автоматизации) и сбор исходных данных. Системный проект. Структура технического задания на проектирование ИС и рекомендации по его формированию.
3.1. Этапы разработки информационных систем
После выбора методологии проектирования автоматизированной информационной системы необходимо спланировать комплекс работ по созданию системы в соответствии с типовыми этапами разработки ИС, краткая характеристика которых приведена в табл. 3.1, а последовательность трансформации бизнес модели в объекты базы данных на рис. 3.1.
Таблица 3.1 – Этапы проектирования ИС и их характеристики
|
№ этапа |
Наименование этапа |
Основные характеристики |
|
1 |
Разработка и анализ бизнес – модели |
Определяются основные задачи ИС, проводится декомпозиция задач по модулям и определяются функции с помощью которых решаются эти задачи. Описание функций осуществляется на языке производственных (описание процессов предметной области), функциональных (описание форм обрабатываемых документов) и технических требований (аппаратное, программное, лингвистическое обеспечение ИС). Метод решения: Функциональное моделирование. Результат: 1.Концептуальная модель ИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации ИС. 2.Аппаратно-технический состав создаваемой ИС. |
|
2 |
Формализация бизнес – модели, |
Разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели ИС. Метод решения: Разработка диаграммы "сущность-связь" (ER (Entity-Reationship) – CASE- диаграммы). Результат: Разработанное информационное обеспечение ИС: схемы и структуры данных для всех уровней модульности ИС, документация по логической структуре ИС, сгенерированные скрипты для создания объектов БД. |
Таблица 3.1 (продолжение)
|
№ этапа |
Наименование этапа |
Основные характеристики |
|
3 |
Выбор лингвистического |
Разработка ИС: выбирается лингвистическое обеспечение (среда разработки – инструментарий), проводится разработка программного и методического обеспечения. Разработанная на втором этапе логическая схема воплощается в реальные объекты, при этом логические схемы реализуются в виде объектов базы данных, а функциональные схемы – в пользовательские формы и приложения. Метод решения: Разработка программного кода с использованием выбранного инструментария. Результат: Работоспособная АИС. |
|
4 |
Тестирование и отладка ИС |
На данном этапе осуществляется корректировка информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п. Результат: Оптимальный состав и эффективное функционирование ИС. Комплект документации: разработчика, администратора, пользователя. |
|
5 |
Эксплуатация и контроль версий |
Особенность ИС созданных по архитектуре клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД ИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%. Результат: Наращиваемость и безызбыточный состав гибкой, масштабируемой ИС |
Рис.3.1- Последовательность трансформации бизнес-модели в объекты БД и приложения
3.2. Проведение обследования деятельности предприятия и построение моделей
3.2.1. Сбор информации для исследования и формализации бизнес-процессов деятельности предприятия или организации
При построении эффективной автоматизированной системы первым этапом является исследование и формализация бизнес-процессов деятельности предприятия. Т.е. описание системы ведения делопроизводства с целью эффективного использования информации для достижения поставленных задач и решения проблем, стоящих перед организацией. Организация работы с документами (будь то платежные или конструкторско-технологические документы) является важной составной частью процессов управления и принятия управленческих решений, существенно влияющей на оперативность и качество управления. Процесс принятия управленческого решения состоит из:
- получения информации;
- переработка информации;
- анализа, подготовки и принятия решения.
Все эти этапы самым тесным образом связаны с документационным обеспечением процессов управления, проектирования и производства. Если на предприятии отсутствует четкая организация работы с документами, то, как следствие этого, закономерно появление документов низкого качества, как в оформлении, так и в полноте и ценности содержащейся в них информации, увеличение сроков их обработки. Это приводит к ухудшению качества управления и увеличению сроков принятия решений и числу неверных решений. С ростом масштабов предприятия и численности его сотрудников вопрос об эффективности документационного обеспечения управления становится все более актуальным. Основные проблемы, возникающие при этом, выглядят примерно так:
- руководство теряет целостную картину происходящего;
- структурные подразделения, не имея информации о деятельности друг друга, перестают слаженно осуществлять свою деятельность. Неизбежно падает качество обслуживания клиентов и способность организации поддерживать внешние контакты;
- это приводит к падению производительности и вызывает ощущение недостатка в ресурсах: людских, технических, коммуникационных и т.д.;
- приходится расширять штат, вкладывать деньги в оборудование новых рабочих мест, помещения, коммуникации, обучение новых сотрудников;
- для производственных предприятий увеличение штата может повлечь изменение технологии производства, что потребует дополнительных инвестиций;
- оказывается, что штат увеличен, производительность упала, производство требует инвестиций, соответственно возникает потребность в увеличении оборотного капитала, что может потребовать новых кредитов и уменьшить плановую прибыль.
В итоге предприятие перестает расти интенсивно и дальнейшее расширение происходит чисто экстенсивным путем за счет ранее созданной прибыли.
Автоматизация информационных процессов призвана решить указанные проблемы.
3.2.2. Обследование деятельности предприятия и сбор данных
Во-первых, необходимо ограничить контекст системы – с этой целью должны быть выявлены все внешние объекты, с которыми моделируемое предприятие взаимодействуют, технологии взаимодействия со стороны предприятия, а также информационные (и, возможно, материальные) потоки, обеспечивающие эти взаимодействия. Во-вторых, должны быть детально выявлены реальные технологии работы предприятия – нормативно-справочная документация (если она имеется) описывает их неполно. В-третьих, должны быть определены реальные функции подразделений и их взаимосвязи и взаимозависимости, поскольку положения о подразделениях такую информацию не содержат. В-четвертых, должны быть выявлены и специфицированы все информационные хранилища (в том числе и бумажные: картотеки, архивы и т.п.). В-пятых, должна быть оценена аппаратно-техническая база предприятия, а также исследовано работающее на ней программное обеспечение. Наконец, в-шестых, должны быть собраны статистические данные по бизнес-процессам предприятия. Остановимся на последнем более подробно.
Статистические данные при проведении обследования необходимо собирать по каждому объекту будущей модели: потоку данных, элементу данных, процессу, хранилищу данных, внешней сущности и т.п. – все они со временем сослужат хорошую службу. Так на этапе анализа моделей наличие подробной статистики обеспечит их адекватную верификацию на полноту и непротиворечивость и позволит на начальных этапах выявить ошибки и узкие места в построенных моделях. В следующих пунктах будет показано, как эти статистические данные работают на дальнейших этапах, начиная с этапа выработки предложений по автоматизации и заканчивая собственно разработкой или внедрением выбранной системы.
1) Составные данные. Для составных данных статистика собирается, как правило, лишь для итеративных (повторяющихся) компонентов – необходимо точно знать количество итераций для каждого из них. Например, заказ на книги включает в себя перечень заказанных книг с их атрибутами. Поэтому для формирования требований к функции распечатки соответствующего бланка необходимо знать: сколько книг обычно заказывается? как часто производится нетипичный заказ и каковы его размеры? Сколько авторов обычно бывает у книги?
Статистика по итеративным компонентам внутри составных данных в дальнейшем будет использоваться для проектирования экранов, отчетов и, естественно, при проектировании базы данных.
2) Элементы данных. О каждом элементе данных необходимо знать формат данных и допустимые значения этого элемента. Формат (включая тип) и физическая длина очень полезны при проектировании экранных форм и определении размеров баз данных.
3) Потоки данных. Такие характеристики потока как скорость и интенсивность являются необходимыми при определении требований к аппаратным (техническим) средствам. Кроме того, для любого составного потока данных полезно знать распределение компонентов внутри этого потока данных. Данная статистика может использоваться для определения пиковых нагрузок на соответствующие обрабатывающие процессы.
4) Процессы. Важнейшими характеристиками процессов являются частота и время выполнения. Именно здесь и лежит ключ к улучшению их функционирования. Кроме того, такие сведения являются необходимыми при определении требований к аппаратным средствам.
5) Хранилища данных. По хранилищам данных обычно собирается следующая информация: среднее количество записей в каждом хранилище данных, количество чтений, добавлений, изменений и удалений записей по каждому из процессов, включающих перечисленные действия. Проектировщик баз данных может использовать эту статистику для нескольких целей – например, решить вопрос, какой ключ считать первичным, сортировать ли хранилище и по какому ключу, решить, нужно ли завести дополнительную таблицу с целью обеспечения скорости доступа и т.д. Более того, к этой информации потребуется обратиться и при выборе подходящей СУБД, которая сможет обеспечить необходимую частоту и/или гибкость доступа к данным.
Ценной информацией является и хронология доступа. Так запись о конкретном заказе, как правило, однажды создается и однажды удаляется. Но обычно доступ к этой записи осуществляется очень часто в начале ее существования (запросы о покупателе, счета, платежи, накладные) и крайне редко в дальнейшем (месячные и квартальные отчеты), что позволяет своевременно осуществлять ее архивацию.
6) Внешние объекты. Наконец, необходимо собрать определенную статистику об окружении, в котором система должна работать ("ограничения окружения"). Наиболее важным здесь является количество пользователей, их способы использования системы и географическое распределение. По этой статистике можно будет сделать заключения о стоимости периферии, о типе системы телекоммуникаций и даже о том, как данные должны быть физически распределены для обеспечения удаленного доступа. Другие данные об окружении могут включать температуру, уровень шума, существующую отделку помещения, уровень радиации и т.п.
Следует отметить, что часто возникает необходимость в проведении дополнительного обследования: какие-то моменты были не до конца выяснены, где-то возникли нестыковки, что-то было просто упущено. Обычно дополнительное обследование занимает 2-3 дня, и при его проведении очень полезно обсудить с интервьюированными уже наработанные модели.
3.2.3. Построение и анализ моделей деятельности предприятия
Построение и анализ моделей деятельности предприятия относится к области бизнес-консалтинга, включающего в себя построение моделей текущего и целевого состояния предприятия, выработку предложений по совершенствованию его деятельности, формирование целевой программы развития предприятия и плана перехода из текущего состояния в целевое. На данном этапе осуществляется обработка результатов обследования и построение функциональных, информационных и, по необходимости, событийных моделей технологий работы предприятия следующих двух видов:
- модели "как есть" (AS IS), представляющей собой "снимок" положения дел на предприятии (оргштатная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнес-процессы и т.д.) на момент обследования и позволяющей понять, что делает и как функционирует данное предприятие с позиций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации;
- модели "как будет" (TO BE), интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков по совершенствованию деятельности предприятия.
При этом переход от модели "как есть" к модели "как будет" обычно осуществляется следующими двумя способами:
- Совершенствованием технологий на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников ("легкий" реинжиниринг);
- Радикальным изменением технологий и переосмыслением бизнес-процессов ("жесткий" реинжиниринг).
В рамках создания моделей деятельности должен быть осуществлен:
- анализ функциональной деятельности структурных подразделений предприятия;
- анализ функционального взаимодействия структурных подразделений;
- анализ внутреннего документооборота структурных подразделений;
- анализ информационных потоков и информационного взаимодействия структурных подразделений;
- анализ применяемых в настоящее время средств автоматизации как в структурных подразделениях, так и на предприятии в целом.
По результатам анализа и моделирования осуществляется оценка эффективности деятельности структурных подразделений предприятия, на основе которой формируются предложения по совершенствованию его структуры, технологий работы структурных подразделений и предприятия в целом. Критериями такой оценки должны являться:
- количество потребителей продукции предприятия;
- стоимость издержек производства продукции;
- длительность типовых операций производства продукции;
- дублирование и противоречивость функций, информационных потоков и документооборота;
- стоимость и длительность выполнения отдельных шагов технологии или отдельных технологических цепочек шагов;
- дублирование и противоречивость выполнения отдельных шагов технологии или отдельных технологических цепочек шагов;
- степень загруженности структурных подразделений и должностных лиц;
- степень загруженности оборудования, используемого при реализации отдельных шагов технологии или технологических участков;
- степень применения средств автоматизации при поддержке выполнения отдельных шагов технологии или отдельных технологических цепочек шагов.
Результатом проведения анализа и оценки являются предложения по совершенствованию деятельности предприятия, а именно:
- по изменению технологий целевой и обеспечивающей деятельности предприятия, операций учета, планирования, управления и контроля;
- по построению рациональных технологий работы структурных подразделений предприятия с учетом существующих автоматизированных систем;
- по созданию перспективной оргштатной структуры предприятия, осуществляющей реализацию рациональных технологий работы;
- по изменению информационных потоков и документооборота, обеспечивающих реализацию рациональных технологий работы;
- по разработке проектов схем внутреннего и внешнего документооборота, проекта положения о документообороте, проекта альбома форм входных и выходных документов.
На основе разработанных и согласованных предложений формируется целевая программа развития предприятия и план мероприятий по переходу из текущего состояния в целевое. Целевая программа развития предприятия должна включать долгосрочные решения, цели, задачи и основные параметры развития. План мероприятий перехода из текущего состояния в целевое должен содержать:
- последовательность, формы, способы и время выполнения задач, поставленных структурным подразделениям предприятия;
- распределение сотрудников структурных подразделении и материальных средств по решаемым задачам;
- порядок информационного и других видов взаимодействия структурных подразделений и органов управления.
В связи с вышесказанным каждая из моделей деятельности должна включать:
- полную функциональную модель с глубиной проработки до уровня конкретного действия должностного лица структурного подразделения предприятия;
- информационную модель, интегрированную с функциональной моделью;
- динамические, стоимостные, событийные и т.п. модели для осуществления соответствующих оценок.
Ниже перечислены основные виды и последовательность работ, рекомендуемые при построении моделей деятельности.
1) Разработка структурной функциональной модели деятельности предприятия:
- определение информационных потоков между основными процессами деятельности, связей между процессами и внешними объектами;
- оценка объемов и интенсивности информационных потоков;
- разработка иерархии диаграмм, образующих структурную функциональную модель деятельности предприятия;
- анализ и оптимизация структурной функциональной модели.
2) Разработка информационной модели предприятия:
- определение сущностей модели и их атрибутов;
- проведение атрибутного анализа и оптимизация сущностей;
- идентификация отношений между сущностями и определение типов отношений;
- разрешение неспецифических отношений;
- анализ и оптимизация информационной модели.
3) Разработка событийной модели предприятия:
- идентификация перечня состояний модели и определение возможностей переходов между состояниями;
- определение условий, активирующих переходы, и действий, влияющих на дальнейшее поведение;
анализ и оптимизация событийной модели.
Следует отметить, что построенные модели деятельностей являются не просто промежуточным результатом, используемым консультантом для выработки каких-либо рекомендаций и заключений. Они представляют собой самостоятельный результат, имеющий большое практическое значение, в частности:
1) Модели позволяют осуществлять автоматизированное и быстрое обучение новых работников конкретному направлению деятельности предприятия (так как ее технология содержится в модели) с использованием диаграмм (известно, что "одна картинка стоит тысячи слов").
2) С их помощью можно осуществлять предварительное моделирование нового направления деятельности с целью выявления новых потоков данных, взаимодействующих подсистем и бизнес-процессов.
Ниже приводятся некоторые основные рекомендации по структурированию моделей деятельности.
1) Основной принцип заключается в том, что структурирование должно осуществляться в соответствии с деятельностями и бизнес-процессами предприятия, а не в соответствии с его оргштатной структурой. Именно бизнес-процессы представляют ценность для клиента, и именно их улучшением предстоит в дальнейшем заниматься консультанту. Модель, основанная на оргштатной структуре, может продемонстрировать лишь хаос, царящий в организации (о котором, в принципе, руководству и так известно, иначе оно не воспользовалось бы услугами консультантов), на ее основе возможно внести предложения только об изменении этой структуры. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе (не всегда в явном виде) и оргштатную структуру предприятия. Такой подход реализует принцип отделения процессов от оргштатной структуры.
2) Верхний уровень модели должен отражать только контекст системы – взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром и ничего более. В случае построения модели структуры, включающей в себя несколько разнотипных предприятий, на контекстном уровне необходимо отразить каждое из них и их соответствующие взаимосвязи.
3) На втором уровне модели должны быть отражены основные деятельности предприятия и их взаимосвязи. В случае большого количества деятельностей некоторые из них можно вынести на третий уровень модели. Но в любом случае под деятельности необходимо отводить не более двух уровней модели.
4) Каждая из деятельностей, в свою очередь, должна быть детализирована на бизнес-процессы (желательно, единственного уровня). Например, деятельность по учету кадров включает в себя бизнес-процессы Прием на работу, Увольнение и т.п.
5) Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций. Так процесс Прием на работу содержит в себе функции Прием заявления, Оформление приказа, Регистрация и др. Обычно для моделирования бизнес-функции достаточно 2-3 уровней детализации, которая завершается описанием элементарного алгоритма с помощью миниспецификации.
Итак, выделим следующие уровни детализации для типовых проектов ИС:
1) система (контекстная диаграмма);
2) подсистема (например, контекстная диаграмма регионального банка Сбербанка РФ содержит подсистемы Территориальное Управление, Типовое Отделение, Типовой Филиал);
3) основные деятельности предприятия (например, обеспечивающая деятельность, основная деятельность);
4) основные процессы, составляющие виды деятельности (учет кадров, бухгалтерский учет, экономическое планирование, материально-техническое снабжение, сбыт продукции, складской учет и т.п.);
5) основные задачи пользователей ИС как части основных процессов (процессы уровня прецедентов или групп прецедентов, такие как прием на работу, увольнение и т.п.);
6) задачи пользователей, выполняемые на уровне прецедентов (обновление справочников, регистрация заявления и т.п.);
7) функции, выполняемые на отдельных шагах сценариев прецедентов (проверка данных, выбор из списка товаров и т.п.);
8) отдельные элементарные операции.
Не все из перечисленных выше уровней должны отражаться в одной диаграмме. Если модель, начиная с контекстной диаграммы, содержит слишком много уровней (более 7), ее можно разделить на несколько отдельных диаграмм. Общее число уровней в модели не должно превышать 6-7. Практика показывает, что этого вполне достаточно для построения полной модели деятельности современного предприятия любой отрасли.
3.2.4. Этапы (стадии) создания ИС
Процесс создания ИС делится на ряд этапов (стадий), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).
Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение [14] .
Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.
Целью начальных этапов создания ИС, выполняемых на стадии анализа деятельности организации, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.
Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.
На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.
Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.
Конечными продуктами этапа проектирования являются:
- схема базы данных (на основании ER-модели, разработанной на этапе анализа);
- набор спецификаций модулей системы (они строятся на базе моделей функций).
Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:
- будет ли это архитектура "файл-сервер" или "клиент-сервер";
- будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
- будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
- будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);.
- будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).
Этап проектирования завершается разработкой технического проекта ИС.
На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.
Этап тестирования обычно оказывается распределенным во времени.
Виды тестов.
1) Автономные тесты. Выполняются после завершения разработки отдельного модуля системы. Преследуют две основные цели:
- обнаружение отказов модуля (жестких сбоев);
- соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).
2) Тесты связей (интеграции). Выполняются после того, как автономный тест успешно пройден и модуль включен в состав разработанной части системы. Группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.
3) Тесты на надежность работы группы модулей. Проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.
4) Системный тест. Тест проводится для всего комплекта модулей и является тестом внутренней приемки продукта, показывающим уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.
5) Приемо-сдаточные испытания – последний тест информационной системы. Испытания предусматривают показ информационной системы заказчику и должны содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.
3.3. Разработка системного проекта
Создание системного проекта (иначе, модели требований к будущей системе) является первой фазой разработки собственно системы автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Если требования нигде не зафиксированы, то их вроде бы и не существует. Системный проект строится на основе модели "как будет" и результатов обследования предприятия в части выявления требований к будущей системе.
Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта ИС. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.
На этом этапе определяются:
- архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;
- интерфейсы и распределение функций между человеком и системой;
- требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;
- состав людей и работ, имеющих отношение к системе;
- ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
В рамках системного проектирования должно быть осуществлено:
- определение состава, структуры и характеристик функциональных задач в рамках деятельности структурных подразделений;
- определение состава и структуры программных средств автоматизации технологии решения задач с учетом существующих средств в структурных подразделениях;
- определение структуры и характеристик информационного обеспечения технологии решения задач;
- разработка технических решений по построению информационного обеспечения (логических структур баз данных, структур классификаторов);
- разработка состава автоматизируемых процедур документооборота. Системный проект должен включать:
- полную функциональную модель требований к будущей системе;
- комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);
- пакет отчетов и документов по функциональной модели, включающий характеристику объекта моделирования, перечень подсистем, требования к способам и средствам связи для информационного обмена между компонентами, требования к характеристикам взаимосвязей системы со смежными системами, требования к функциям системы;
- концептуальную модель интегрированной базы данных (пакет диаграмм);
- архитектуру системы с привязкой к концептуальной модели;
- предложения по оргштатной структуре для поддержки системы.
Таким образом, системный проект содержит функциональную, информационную и, возможно, событийную модели требований к будущей системе. Виды и последовательность работ при построении этих моделей требований аналогичны соответствующим работам по построению моделей деятельности. Дополнительно системный проект включает в себя техническое задание на создание ИС.
Необходимо отметить следующее достоинство системного проекта. Для традиционной разработки характерно осуществление начальных этапов кустарными неформализованными способами. В результате заказчики и пользователи впервые могут увидеть систему после того, как она уже в большей степени реализована. Естественно, эта система отличается от того, что они ожидали увидеть. Поэтому далее следует еще несколько итераций ее разработки или модификации, что требует дополнительных (и значительных) затрат денег и времени. Ключ к решению этой проблемы и дает системный проект, позволяющий:
- описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;
- уменьшить затраты на разработку и внедрение системы;
- оценить разработку по времени и результатам;
- достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.);
- улучшить качество разрабатываемой системы, а именно: создать оптимальную
- структуру интегрированной базы данных, выполнить функциональную
- декомпозицию типовых модулей.
Системный проект полностью независим и отделяем от конкретных разработчиков, не требует сопровождения его создателями и может быть безболезненно передан другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации системы на основе проекта, он может быть положен "на полку" до тех пор, пока в нем не возникнет необходимость. Кроме того, его можно использовать для самостоятельной разработки или корректировки уже реализованных на его основе программных средств силами программистов отдела автоматизации предприятия.
3.4. Разработка предложений по автоматизации и техническое предложение
После построения системного проекта, содержащего требования к будущей системе, на его основе осуществляется разработка предложений по автоматизации предприятия, включающая в себя:
- составление перечня автоматизированных рабочих мест предприятия, их состава и структуры, а также способов и схем информационного взаимодействия между ними;
- разработку требований к техническим средствам;
- разработку требований к программным средствам;
- разработку топологии, состава и структуры локальной вычислительной сети;
- анализ имеющихся на рынке систем управления предприятием с учетом их соответствия системному проекту и формирование рекомендаций по выбору такой системы;
- совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием (или отдельных ее элементов) или о разработке собственной системы;
- разработку предложений по этапам и срокам автоматизации.
Далее рассматриваются общие соображения по выбору программного и технического (аппаратного) обеспечения, который необходимо сделать, прежде чем приступить к детальному проектированию.
1) Обозначение границ реализации. Практически любая система может быть разбита на части, отражающие четыре основных типа реализации систем: ручную, пакетную, диалоговую, реального времени. Из этих четырех типов первый реализуется людьми, остальные три являются автоматическими реализациями системы. Рассмотрим критерии назначения частям системного проекта наиболее приемлемых для них типов реализации.
Ручная реализация имеет три основных преимущества перед автоматической:
- процессы не требуется заранее точно определять. По крайней мере, они могут определяться не так тщательно как при автоматической реализации: люди хорошо знают, как заполнить пробелы в спецификации;
- ручная система может откликаться на неожидаемые запросы, а не только на заранее планируемые;
- система может быть реализована в окружении, где автоматизация невозможна по целому ряду причин, например, психологических: хотя и возможно полностью автоматизировать процесс предоставления ссуды, люди не могут примириться с тем, что их прошения беспристрастно отклонены машиной.
Безусловно, ручные системы имеют массу недостатков. Например, люди устают, болеют, увольняются, требуют повышения зарплаты. Однако наиболее важно, что размер и сложность ручной системы будут возрастать с увеличением числа запросов, поскольку человек может обрабатывать лишь небольшое количество данных.
После определения границ ручной реализации необходимо решить, какая часть системы должна быть пакетной, а какая диалоговой? Для большинства современных приложений вся автоматизированная система должна быть диалоговой, если только не доказано обратное. Соответствующее заключение может быть сделано на основе собранных статистических данных, например скорости поступления запросов и частоты изменения данных. В качестве примеров причин для пакетной реализации можно привести следующие:
- некоторые запросы требуют длительной работы со срезом базы данных за определенный период (годовой отчет, пересылка накопленной информации и т.п.);
- некоторые отклики (например, отчеты о продажах) содержат большое количество статичных данных, актуальность которых не изменяется в течение дней или даже недель.
Следующий шаг – выделение частей, реализуемых как подсистемы реального времени. Существует два принципиальных отличия системы реального времени от просто диалоговой системы. Первое из них связано с концептуальным уровнем: в системе реального времени время поступления события в систему само по себе несет определенную информацию, которая не может быть закодирована. Второе связано с уровнем реализации: время отклика системы реального времени является критичным и сопоставимым со скоростью выполнения технологических операций. В целом, рекомендуется реализовать как подсистемы реального времени те части системы, из которых должен быть исключен человек, то есть те части, в которых приоритетны следующие факторы: скорость (например, противоракетная оборона), опасность (например, контроль радиоактивности), утомляемость (работа авиадиспетчера).
2) Выбор подходящих технических средств. Разработав системный проект и определив границы реализации, можно начинать выбор аппаратной платформы, на которой будет функционировать система (или, по крайней мере, сужать область для такого выбора).
3) Анализ и выбор существующей системы. Зная типы подсистем и потенциальную аппаратную платформу, можно приступать к поиску коммерческих пакетов, которые удовлетворяют требованиям, выявленным и зафиксированным на этапе системного проектирования, и могут справиться с размерами и мощностью, определяемыми собранной статистикой. Следует отметить, что к такому выбору необходимо подходить особо тщательно: стоимость интегрированной системы (включая ее внедрение на предприятии), в комплексе решающей стоящие перед предприятием задачи, может составлять сотни и миллионы долларов, а ключевые слова, характеризующие различные системы, практически одни и те же:
- единая информационная среда предприятия;
- режим реального времени;
- независимость от законодательства;
- интеграция с другими приложениями (в том числе с уже работающими на предприятии системами);
- поэтапное внедрение и т.п.
И здесь неоценимую помощь оказывает системный проект, позволяющий выбрать систему, наиболее полно подходящую конкретному предприятию, либо отвергнуть данный путь и приступить к разработке и реализации собственной системы.
Ниже перечислены некоторые из критериев выбора готовой системы:
- поддержка большинства функций, выявленных при анализе требований;
- поддержка концептуальной модели данных;
- наличие высокоуровневых механизмов разработки для компенсации отсутствующих данных и функций;
- функционирование на различных аппаратных платформах;
- достаточные размеры внутренних таблиц;
- локализация.
Помимо чисто технических критериев выбора, важную роль играют также деловые критерии, например, опыт внедрения и надежность продавца.
4) Разработка собственной системы. Отметим недостатки такого подхода по сравнению с покупкой готовой системы:
- трудозатраты на создание собственной интегрированной системы огромны и составляют сотни и тысячи человеко-лет, стоимость разработки соизмерима со стоимостью готовой системы (а часто значительно превышает ее): такие продукты должны реализовываться большими коллективами программистов;
- использование готовой системы менее рискованно, чем разработка собственной;
- готовая система внедряется поэтапно и поэтому частично может быть доступна в рабочем режиме гораздо быстрее, чем собственная.
Техническое проектирование
На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: "Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?". Этот этап разделяется на два подэтапа:
- проектирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;
- детальное проектирование, включающее разработку спецификаций каждой компоненты, разработку требований к тестам и плана интеграции компонент, а также построение моделей иерархии программных модулей и межмодульных взаимодействий и проектирование внутренней структуры модулей.
При этом происходит расширение системного проекта:
- за счет его уточнения;
- за счет построения моделей автоматизированных рабочих мест, включающих подсхемы информационной модели и функциональные модели, ориентированные на эти подсхемы вплоть до идентификации конкретных сущностей информационной модели;
- за счет построения моделей межмодульных и внутримодульных взаимодействий с использованием техники структурных карт.
Центральное место среди перечисленных видов работ занимает построение моделей автоматизированных рабочих мест (АРМ).
3.5. Разработка технического задания
3.5.1. Назначение технического задания и его структура
Техническое задание (ТЗ) — исходный документ для конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, либо проведения научно-исследовательских работ.
ТЗ содержит основные технические требования, предъявляемые к изделию или программному комплексу и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т. п.) документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.
Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет достичь следующих целей.
Обеим сторонам:
- представить готовый продукт;
- выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний);
- уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).
Заказчику:
- осознать, что именно ему нужно, в том числе опираясь на существующие на данный момент технические возможности и свои ресурсы;
- требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.
Исполнителю:
- понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы
- спланировать выполнение проекта и работать по намеченному плану
- отказаться от выполнения работ, не указанных в ТЗ
Техническое задание — исходный документ, определяющий порядок и условия проведения работ по Договору, содержащий цель, задачи, принципы выполнения, ожидаемые результаты и сроки выполнения работ.
Техническое задание на автоматизированную систему (ТЗ на АС) — документ, являющийся разновидностью технического задания для автоматизированных систем.
В СССР был разработан стандарт ГОСТ 34.602-89, определяющий требования к содержанию технического задания на автоматизированную систему.
Зарубежным аналогом стандарта ГОСТ 34.602-89 ТЗ на АС является стандарт IEEE Std 830 и стандарт IEEE Std 1233-1998 – Guide for Developing System Requirements Specifications.
Эти стандарты наиболее близки к определению требований к ИС как разновидности автоматизированных систем.
Техническое задание составляется по результатам предпроектного обследования объекта автоматизации. В настоящее время при составлении технического задания обычно руководствуются требованиями следующих ГОСТов:
a) 34.602-89 «Техническое задание на создание автоматизированной системы» – описывает состав и содержание ТЗ, которые распространяются на автоматизированную (информационную) систему в целом, в том числе:
- общесистемные требования к ИС;
- требования к компонентному составу ИС;
- требования к интеграции компонентов ИС между собой и с другими системами;
- требования к составу и содержанию работ по внедрению ИС;
- …
б) 19.201-78 «Техническое задание. Требования к содержанию и оформлению» – входит в единую систему программной документации и устанавливает порядок построения и оформления технического задания на программное изделие для ЭВМ.
При проектировании сложных систем обычно разрабатывают общее техническое задание на ИС в целом (в соответствии с требованиями ГОСТ 34.602-89), а также дополнительные технические задания на части системы:
- на создание информационно-вычислительной сети,
- на отдельные подсистемы ИС,
- на элементы программного обеспечения ИС – программные компоненты и/или комплексы (в соответствии с требованиями ГОСТа 19.201-78).
Для сравнительно небольших информационных систем допускается разработка единого технического задания, в котором устанавливаются как общие требования к ИС, так и требования к соответствующим программным средствам.
В соответствии с ГОСТом 19.201-78 техническое задание должно включать в себя следующие разделы:
- Введение;
- Основание для разработки;
- Назначение и цели разработки;
- Требования к программе и программной документации;
- Технико-экономические показатели;
- Стадии и этапы разработки;
- Порядок контроля и приёмки;
- Приложение.
УКАЗАНИЯ ГОСТ 34.602-89: Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т.п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее – ТЗ на АС).
В выполняемых студентами курсовых и дипломных проектах техническое задание как отдельный документ, как правило, не оформляется, можно рекомендовать поместить в проект раздел «Разработка технического задания» как часть пояснительной записки.
Ниже приведены методические рекомендации по разработке ТЗ на программное изделие (программный комплекс, систему автоматизации, информационную систему), включающие примеры содержания.
Разделы, которые не прорабатываются в студенческих проектах, опущены.
При разработке ТЗ разделы, не являющиеся обязательными, могут быть опущены. Нумерация выполняется в соответствии оставленными в пояснительной записке разделами (ниже в примерах нумерация соответствует ГОСТ).
Разделы ТЗ, которые не требуется разрабатывать в учебных проектах, помечены знаком **. Разделы ТЗ, которые можно исключить (или оставить, в зависимости от тематики) в учебных проектах, помечены знаком *.
Структура ТЗ:
1 ОБЩИЕ ПОЛОЖЕНИЯ
1.1 Полное наименование системы и ее условное обозначение
1.2 Номер договора (контракта)**
1.3 Наименования организации-заказчика и организаций-участников работ**
1.4 Перечень документов, на основании которых создается система*
1.5 Плановые сроки начала и окончания работы по созданию системы*
1.6 Источники и порядок финансирования работ**
1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы**
1.8 Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ*
1.9 Определения, обозначения и сокращения*
2 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
2.1 Назначение системы
2.2 Цели создания системы
3 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
4.1 Требования к системе в целом
4.1.1 Требования к структуре и функционированию системы
4.1.1.1 Перечень подсистем, их назначение и основные характеристики
4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы
4.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами
4.1.1.4 Требования к режимам функционирования системы
4.1.1.5 Требования по диагностированию системы*
4.1.1.6 Перспективы развития, модернизации системы
4.1.2 Требования к численности и квалификации персонала системы
4.1.3 Показатели назначения
4.1.4 Требования к надежности
4.1.5 Требования к безопасности
4.1.6 Требования к эргономике и технической эстетике
4.1.7 Требования к транспортабельности для подвижных АС*
4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы*
4.1.9 Требования к защите информации от несанкционированного доступа
4.1.10 Требования по сохранности информации при авариях
4.1.11 Требования к защите от влияния внешних воздействий*
4.1.12 Требования к патентной частоте*
4.1.13 Требования по стандартизации и унификации*
4.1.14 Дополнительные требования*
4.2 Требования к функциям (задачам), выполняемым системой
4.3 Требования к видам обеспечения
4.3.1 Требования к математическому обеспечению системы
4.3.2 Требования информационному обеспечению системы
4.3.3 Требования к лингвистическому обеспечению системы
4.3.4 Требования к программному обеспечению системы
4.3.5 Требования к техническому обеспечению
4.3.6 Требования к метрологическому обеспечению
4.3.7 Требования к организационному обеспечению
4.3.8 Требования к методическому обеспечению
5 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ (РАЗВИТИЮ) СИСТЕМЫ*
6 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ**
6.1 Виды, состав, объем и методы испытаний системы**
6.2 Общие требования к приемке работ по стадиям**
6.3 Статус приемочной комиссии**
7 ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ**
8 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
9 ИСТОЧНИКИ РАЗРАБОТКИ*
3.5.2. Рекомендации по заполнению разделов технического задания
1 ОБЩИЕ ПОЛОЖЕНИЯ
1.1 Полное наименование системы и ее условное обозначение
ПРИМЕР СОДЕРЖАНИЯ:
Полное наименование системы: Информационная система складского учета "ИС Склад ".
Краткое наименование системы: ИС «Склад».
1.4 Перечень документов, на основании которых создается система
ПРИМЕР СОДЕРЖАНИЯ:
Основанием для разработки ИС «Склад» является:
- приказ на дипломное проектирование N от ______.
- концепция информатизации предприятия … на 2010-2012 годы.
1.8 Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ *
ФОРМАЛЬНОЕ СОДЕРЖАНИЕ:
При разработке автоматизированной системы Исполнитель должен руководствоваться требованиями следующих нормативных документов:
– ГОСТ 19.201-78. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ;
– ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;
– ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение документов при создании автоматизированных систем;
– РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.
- т.д.
2 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
УКАЗАНИЯ ГОСТ:
В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать.
ПРИМЕР СОДЕРЖАНИЯ:
ИС «Склад» предназначена для комплексной автоматизации работы склада предприятия ХХХ, в части исполнения следующих процессов:
- оперативного учета движения товаров;
- ведения учета прихода и расхода товаров;
- ведение архивов без ограничения сроков давности;
…
ИС «Склад» предполагается использовать на предприятии ХХХ и его филиалах, задействованных в исполнении вышеперечисленных процессов.
УКАЗАНИЯ ГОСТ:
В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.
Обычно данный подраздел содержит как формальное, так и реальное описание достигаемых целей.
ПРИМЕР СОДЕРЖАНИЯ:
Основными целями создания ИС «Склад» являются:
- Замещение существующей информационной системы, которая не предоставляет возможность комплексного информационно-аналитического обеспечения процессов, перечисленных выше, измененных в связи с вводом новых правил складского и бухгалтерского учета.
Существующая информационная система является морально устаревшей, не отвечает современным требованиям, предъявляемым к информационным системам (разработана под ОС DOS), в связи с чем ее дальнейшее развитие нецелесообразно.
- Повышение эффективности исполнения процессов, перечисленных выше, путем сокращения непроизводительных и дублирующих операций, операций, выполняемых «вручную», оптимизации информационного взаимодействие участников процессов.
- Повышение качества принятия управленческих решений за счет оперативности представления, полноты, достоверности и удобства форматов отображения информации;
Для реализации поставленных целей система должна решать следующие задачи:
- Ввод данных реестров;
- Редактирование данных реестров;
- Построение аналитических отчетов и выписок;
- Интегрироваться с существующими АИС других государственных органов;
- т.п.;
3 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
УКАЗАНИЯ ГОСТ:
1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
ПРИМЕР СОДЕРЖАНИЯ:
Объектом автоматизации являются процессы по управлению складскими запасами, а также контроль эффективности выполнения указанных процессов.
Процессы управления складскими запасами включают в себя:
…
Данные процессы осуществляются следующими специалистами:
- Экономистами планово-экономического отдела или отдела труда и заработной платы;
- Работниками отдела снабжения
- Руководителями различного уровня, в т.ч. и высшим руководством;
…
Также в этом разделе можно описать "Существующее программное обеспечение":
ПРИМЕР СОДЕРЖАНИЯ:
В настоящий момент на предприятии в области управления складскими запасами и смежных областях разработаны и внедрены следующие информационные системы:
- Система документооборота;
- Система планирования складских запасов
…
Система документооборота:
- Система реализована сотрудниками предприятия.
- Система используется экономистами планово-экономического отдела.
- Система реализует следующие функции: …
Также в этом разделе можно описать "Существующее техническое обеспечение":
ПРИМЕР СОДЕРЖАНИЯ:
Телекоммуникационная инфраструктура развернута на базе оборудования, принадлежащего предприятию ХХХ.
Каждый филиал предприятия имеет выделенный сервер БД.
Все серверы БД объединены в единую телекоммуникационную сеть по выделенным линиям с пропускной способностью 1 Мб/сек.