Автор Тема: Техническое задание на АС и должностные инструкции  (Прочитано 1225 раз)

kalex

  • Newbie
  • *
  • Сообщений: 12
  • Рейтинг читателей: 3
    • Просмотр профиля
И еще о точных терминах.
Должностные инструкции не являются частью системы и не относятся к системе.
Это документы организации, в которых указываются обязанности СОТРУДНИКА. Не надо пытаться использовать  для них 34 серию ГОСТ.
В лучшем случае в них может быть ссылка на инструкции к тому ПО, которым сотрудник должен пользоваться при выполнении своих должностных обязанностей. А можно ограничиться формулировкой, избегая указывать наименования (коды) документов-инструкций, ограничившись наименованием ПО. Под этим ПО может быть как обычное офисное, так и то, что является одной из компонент конкретной АС.
Для системы должны предусматриваться инструкция ПОЛЬЗОВАТЕЛЯ, администратора, системного программиста.
Разницу понимаете? Пользователь - это роль. Разные сотрудники могут авторизоваться в системе с одной и той же ролью пользователя, при этом они могут быть сотрудниками с разными окладами, из разных подразделений и у них, соответственно, будут разные должностные обязанности.

При том подходе, методология которого предлагается 34 ГОСТом, и который Сергей() проявил желание соблюсти, вполне можно подготовить необходимый набор документов/материалов (которые великолепно описывают все необходимые аспекты). Важно их грамотно "вплести" в деятельность предприятия (в составе приказов, пользователских инструкций и др. организационно-распорядительный и методических документов), чтобы обеспечить эффективное использование системы.
« Последнее редактирование: 27 Сентября 2017, 15:24:12 от kalex »


SALar

  • Member of CAR
  • Sr. Member
  • *****
  • Сообщений: 489
  • Рейтинг читателей: 33
    • Просмотр профиля
    • 255 ступеней
34.602 Можно писать чтобы тендеры выигрывать, а можно, чтобы работало.
Если, чтоб работало, то в ТЗ я бы записал требование к должностным инструкциям. Что они должны быть созданы в рамках проекта. Перечислить какие инструкции должны быть и т.д. (желательно).
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/

Сергей()

  • Full Member
  • ***
  • Сообщений: 165
  • Рейтинг читателей: 2
    • Просмотр профиля
Деление по видам обеспечения, по подсистемам и компонентам не следует смешивать.
Да, я это понимаю, что это разные вещи. Поэтому-то и поднял этот вопрос.

Кстати, термина "подсистема" в ГОСТ 34.003-90 не определено ))
Зато есть понятие "Функциональная подсистема АСУ "(ФП АСУ) по ГОСТ 24.701-86
Значит, скорее всего когда упоминается «подсистема», имеется ввиду именно «функциональная подсистема».

То есть получается так.
Обеспечение – это все, из чего состоит система, конкретные элементы системы.
Подсистема (функциональная подсистема) – это совокупность элементов АСУ (конкретных элементов обеспечения), которые выполняют конкретную функцию системы, то есть выделенных по функциональному признаку.
Компонент – это совокупность элементов АСУ (конкретных элементов обеспечения), объединенных по любому другому не-функциональному признаку.

Согласны?

Должностные инструкции не являются частью системы и не относятся к системе. Это документы организации, в которых указываются обязанности СОТРУДНИКА. Не надо пытаться использовать  для них 34 серию ГОСТ.
В лучшем случае в них может быть ссылка на инструкции к тому ПО, которым сотрудник должен пользоваться при выполнении своих должностных обязанностей…
Мы в них пропишем ссылку на «Порядок выполнения бизнес-процесса ХХХ».
Вот этот порядок наверно будет частью системы?

Разницу понимаете? Пользователь - это роль. Разные сотрудники могут авторизоваться в системе с одной и той же ролью пользователя, при этом они могут быть сотрудниками с разными…
Да, это понятно.

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

Если, чтоб работало, то в ТЗ я бы записал требование к должностным инструкциям. Что они должны быть созданы в рамках проекта. Перечислить какие инструкции должны быть и т.д. (желательно).
Да, так мы и задумывали.
Чтобы наша АС работала, эти инструкции должны быть.

Вернее, сами инструкции уже есть.
Мы впишем в ТЗ требование, что в них нужно внести изменения, необходимые для работы нашей АС.
Как я писал выше, мы в инструкции вставим ссылку на "Порядок выполнения бизнес-процесса ХХХ".

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

« Последнее редактирование: 29 Сентября 2017, 15:52:39 от Сергей() »

kalex

  • Newbie
  • *
  • Сообщений: 12
  • Рейтинг читателей: 3
    • Просмотр профиля
Обеспечение – это все, из чего состоит система, конкретные элементы системы.
Не так. АС не состоит из видов обеспечения. Каждый из  видов обеспечения отражает, как систему можно описать с перечисленных  позиций: какая математика там должна быть реализована вообще, какая информация и в каком виде должна обрабатываться  (храниться, передаваться, отображаться), какие правоотношения и как следует отрегулировать в связи с функционированием, и т.д. по всем другим видам обеспечения.
Предложу такую аналогию. Вы строите систему, разрабатываете ТЗ. Вы в общем знаете ее назначение и функционал и приблизительно как она будет работать. У вас в команде есть спец по каждому виду обеспечения - математик, юрист, спец по базам данных, программист, руководитель подразделения, которое будет ее использовать,  дизайнер-"эргономист",  и т.д. Каждый   из них, допустим, сперва для ТЗ разрабатывает требования в своей части. Ну а потом, допустим, формирует соответствующие решения.
Ещё раз: виды обеспечения - это не структура, это точки зрения.

Сергей()

  • Full Member
  • ***
  • Сообщений: 165
  • Рейтинг читателей: 2
    • Просмотр профиля
Не так. АС не состоит из видов обеспечения.
А я не говорил про "виды обеспечения".
Раз есть виды, значит есть конкретные элементы, которые можно по определенному признаку разделить на эти виды.
Вот про эти конкретные элементы АС я и говорил в определении "обеспечения".
То есть я имел ввиду, что (повторю свое определение):
обеспечение - это конкретные элементы системы, их совокупность.


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


Так будет правильно?
« Последнее редактирование: 30 Сентября 2017, 12:36:20 от Сергей() »

kalex

  • Newbie
  • *
  • Сообщений: 12
  • Рейтинг читателей: 3
    • Просмотр профиля
Не уверен, что следует подходить через "группировку" элементов по видам.
Главное, что следует учитывать  (и, надеюсь, удалось довести) - что описание по каждому их видов обеспечения и описание структуры системы (по функциональным подсистемам) - это разные подходы, формирующие вместе несколько моделей системы. Совокупность всех этих моделей наиболее полно описывает необходимую систему.
Как в будущей работе по созданию (развитию) вы сможете использовать эти модели (или создавать дополнительные) - это уже воля автора и самая интересная часть работы.
Практика дальше вам поможет  ;)

Григорий Печенкин

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 1340
  • Рейтинг читателей: 59
    • Просмотр профиля
    • http://www.greesha.ru
Вот ещё статья Михаила Острогорского, простым языком о компонентах, подсистемах и видах обеспечения.
http://philosoft-services.com/gost34asconcept.zhtml
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)