1

Обучение / Re: Инструментальные средства информационных систем

« : 08 Октября 2018, 11:09:03 »

Возьмем такое средство как 1С. Это средство используется как средство проектирования, реализация ИС, но в то же время это и основа существование ИС. Так можно ли отнести 1С к инструментальным средствам или это что-то иное?

Какое именно средство из всего семейства 1С вы имеете ввиду? Язык, платформу, конфигурацию, или одно из готовых коробочных решений типа Бухгалтерия, ЗиК, Управление предприятием? Или сконфигурированный готовый продукт, используемый на конкретном предприятии (с учетными записями пользователей, реальными документами и данными)?

Тут целая иерархия уровней абстракции.
И, кстати, вопрос (у меня во всяком случае возник) - при таком рассуждении к обсуждаемым "средствам ИС" стоит ли также относить язык программирования?

2

Обучение / Re: Инструментальные средства информационных систем

« : 05 Октября 2018, 18:28:52 »

Коллеги, а есть ли возможность обратиться к источнику наименования дисциплины для уточнения замысла, что под этим наименованием понималось?
В наименовании дисциплины я не нашел слов, описывающих набор инструментальных средств, выходящих за рамки  этапа эксплуатации ИС.
Приведу прямую аналогию: инструментальные средства ЧПУ. Под этим в первую очередь будет пониматься оснастка, используемая станком при обработке заготовок. Но никак не инструмент, используемый при проектировании и изготовлении самого станка.

При упоминании какого-либо инструментария вообще предусматриваются специальные средства, используемые в некой деятельности, каком-то процессе. Обычно эта деятельность указывается прямо, или ее можно легко выявить. Например: инструментальные средства анализа, инструмент сварщика, инструментальные средства для выполнения токарных работ. То есть в процессе функционирования, в рамках штатной работы, при выполнении должностных обязанностей, если угодно.
Используя этот подход под указанным наименованием дисциплины видятся некие средства, которые использует ИС в ходе ее функционирования. Что под этим понимается - это другой вопрос. Если искать на него ответ, то я бы предложил в общем виде состав компонентов АС по ГОСТ 34.003 (т.к. в состав АС они включены, а для ИС могут являться и внешними ресурсами/инструментами)

3

Для всех / Re: Правильные ли этапы проектирования программной системы?

« : 07 Ноября 2017, 10:57:18 »

Constantine1911, интересный взгляд на разработку системы.
Я так понимаю, аспекты "бизнеса" здесь не рассматриваются. Предполагаю, предметная область вам близка и знакома и ее анализ для построения системы вы не выполняете. Или все необходимые материалы у вас уже имеются?

В предложенном вами варианте, где сначала разрабатываются диалоговые окна, а затем логика приложения, - скорее всего после описания логики придется возвращаться назад и переделывать диалоги.
Анализ функциональных требований после разработки опять же диалоговых окон? А где, собственно, сама разработка требований? Если под словом "анализ" она и предполагалась, то очень уж поздно. Вообще, последовательность очень странная. У меня сложилось впечатление, что ваше проектирование не является продолжением работы по созданию системы, а является её началом. И именно поэтому работы по проектированию чередуются с формированием требований к системе/ПО.

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

4

Системный Анализ и Требования / Re: Техническое задание на АС и должностные инструкции

« : 02 Октября 2017, 10:43:21 »

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

5

Системный Анализ и Требования / Re: Техническое задание на АС и должностные инструкции

« : 29 Сентября 2017, 23:16:04 »

Обеспечение – это все, из чего состоит система, конкретные элементы системы.

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

6

Системный Анализ и Требования / Re: Техническое задание на АС и должностные инструкции

« : 27 Сентября 2017, 12:58:01 »

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

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

7

Системный Анализ и Требования / Re: Техническое задание на АС и должностные инструкции

« : 27 Сентября 2017, 12:17:13 »

* пользователи системы - все те, кто ПОЛЬзуются ей (непосредственно взаимодействует с системой через ее интерфейсы , человек (оператор) - чаще всего визуально - через графический интерфейс) или результатами ее работы (разного рода руководители, которые сами могут не сидеть за монитором и которым приносят распечатки или др. материалы из выходных данных)
* обеспечивают функционирование все те, кто ОБЕСПЕЧИВАЮТ ее работоспособность - системный администратор, системный программист, электрик, кто фильтры на блоках питания серверов меняет и т.д.

У пользователей системы есть конкретные цели - выполнить некую задачу с использованием АС (ИС) и получить некий результат этой задачи. Эта задача каким-то образом связана с бизнес-целью предприятия.
Обеспечивающему персоналу от этой системы ничего не нужно. Только чтобы она не создавала им проблем - не ломалась в их смену, например.

Деление по видам обеспечения, по подсистемам и компонентам не следует смешивать.
Компонент - часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое [из п. 2.13 ГОСТ 34.003-90].
В числе компонентов в указанном ГОСТ перечислены все виды обеспечения (помимо персонала, КСА, инф. баз, изделий,  ПТК).
Будет проще понять виды обеспечения, если не пытаться найти их на функциональной структуре конкретной АС, а рассматривать как аспекты, с точки зрения которых следует описывать АС. То есть дополнительный уровень декомпозиции АС, логический. Они определяют специфическую модель обеспечения АС.
Структурно в составе АС можно выделить подсистемы, каждую из которых, в свою очередь, можно рассматривать с точки зрения все тех же видов обеспечения.
Допускаю, если в составе конкретной системы можно определить некий признак (или несколько), по которому в составе системы можно выделить различные элементы, то таким образом систему можно будет декомпозировать иным способом на соответствующие компоненты, и это не будет противоречить ГОСТу.

P.S.
Кстати, термина "подсистема" в ГОСТ 34.003-90 не определено ))
Зато есть понятие "Функциональная подсистема АСУ "(ФП АСУ) по ГОСТ 24.701-86
Функциональная подсистема АСУ "(ФП АСУ) - Подсистема АСУ, выделенная по функциональному признаку и представляющая собой совокупность элементов АСУ (технических, программных, эргатических), участвующих в выполнении некоторой функции системы [из п. 7 Таблицы Приложения 1 ГОСТ 24.701-86]

При этом АСУ или любую ее функциональную подсистему рассматривают как состоящую из трех основных компонентов (групп однородных элементов) - комплекса технических средств (КТС), программного обеспечения (ПО), персонала [из п. 3 Таблицы Приложения 1 ГОСТ 24.701-86]

8

Системный Анализ и Требования / Re: Техническое задание на АС и должностные инструкции

« : 26 Сентября 2017, 17:55:57 »

1. В вашем случае вы планируете дорабатывать существующую СЭД для обеспечения автоматизации определенной деятельности - бизнес-процесса, реализующего "маршрут" документа. На языке ГОСТа это называется развитие АС . Развитие состоит в расширении функционала АС - т.е. реализации новой функции (см. ГОСТ 34.003).
2. АС в числе прочих компонент включает персонал - как пользователей, так и эксплуатационный (т.е. тех, кто обеспечивает функционирование).
Материал, являющийся контентом пользовательских инструкций (или должностными в вашем конкретном случае) относится к методическому (иногда к организационному) обеспечению АС.

И к термину: Автоматизированная система (АС) - система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций [из п. 1.1 ГОСТ 34.003-90].
Дополнительно: документация также входит в состав АС.

9

Управление Проектом / Re: Создание логики для устройства

« : 15 Июля 2017, 23:13:06 »

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

10

Идеи и мозговой штурм / Re: Описание связей между типами документов компании

« : 14 Июля 2017, 10:57:37 »

Соглашусь с коллегой Galogen . И, пожалуй, дополню.
Вопрос не в выборе нотации. Это лишь инструмент донесения смысла. Вопрос, прежде всего, в способах классификации.
Задачка своеобразная и, возможно, определена не полностью. Для какой цели это нужно? Просто систематизировать для реестра и организации единого места хранения, их дальнейшей актуализации? Тогда следует разделять на группы типов - те, которые уже перечислены (инструкции, положения, стратегия...) и предусмотреть просто типизацию (возможно, с системой кодирования).
Если для отслеживания, в каких бизнес-процессах используются/разрабатываются какие документы - то это другой подход - здесь без моделей бизнес-процессов в специальных нотациях не обойтись.
Если необходимо создать методологию документирования в компании - то это получится что-то типа упрощенного ГОСТ 34.201-89 (Виды, комплектность и обозначение документов при создании автоматизированных систем) и РД 50-34.698-90 (Требования к содержанию документов), где указаны требования к составу и содержанию документов.

11

Идеи и мозговой штурм / Re: Нужна помощь в проектировании системного процесса offline расчета скидок

« : 29 Июня 2017, 20:52:04 »

Надеюсь, моя ремарка будет не слишком задержавшейся )

Коллеги здесь уже указывали верный подход.
Основной риск выбранного решения - это выделение отдельной  систему для процессинга акций/скидок, и, таким образом, снижение надежности (а значит и повышение вероятности сбоя/отказа) системы вцелом при проведении расчетов. Но, догадываюсь, что архитектурное решение не подлежит обсуждению. Решение принималось не вами и без необходимой глубины (сам сейчас нахожусь в ритейле и решаю сходные задачи).
Так вот - в предложенном случае стоит с одинаковым успехом рассчитывать на выполнение расчета скидок смежной системой как при первом обращении, так и при изменении списка покупок. Лишние признаки расчета вряд ли идеологически защитят.

12

IDEF ARIS BPMN и пр. / Re: Проверить описание процесса работы программы в нотации IDEF

« : 20 Июня 2017, 17:29:57 »

Первое и основное - неудачно выбрана нотация.
IDEF0 отлично подходит для описания процессов ПРЕДПРИЯТИЯ на очень высоком уровне. Буквально - как одновременно выполняются различные работы в различных цехах/департаментах и как в принципе происходит взаимодействие между ними, преобразование потоков ТМЦ и сведений/документов.
Для выбранной задачи это весьма и весьма неподходящий вариант. Аргумент - как минимум в этой нотации отсутствует узел ветвления, связанный с принятием решения, который всегда присутствует при разработке ПО или системы вообще.
Для описания отдельного бизнес-процесса подойдет CFFC (Cross-Functional Flow Chart), EPC или bpml-bpmn.
Для процесса обработки системой подойдет UML (Activity) или блок-схема алгоритма. UML , в принципе, можно использовать и для моделирования бизнес-процесса, но это не целевой вариант его применения, хотя имеющиеся элементы нотации вполне позволяют его применять для задач BA.
То, что на схеме присутствуют два "инструмента" - система и пользователь, указывает на то, что следовало моделировать бизнес процесс в виде их последовательного взаимодействия - такая модель была бы отличным вариантом пользовательских требований.

13

Для всех / Re: Есть ТЗ и формализация требований заказчика, укажите на ошибки

« : 21 Мая 2017, 23:37:33 »

Спасибо большое, учту Ваше мнение. Подскажите какие ещё ГОСТы актуальны для изучения?

Методологическая база для информационных (и не только) систем - ГОСТы 34 серии. Конкретно по ПО -  ГОСТы 19 серии. Но, боюсь, сами эти документы без достаточной практической работы в соответствии с ними пользы не принесут, только могут помешать. Они полезны когда есть заказчик, работающий по ним, или человек со своей стороны, владеющий ими на уровне методологии.

14

Для всех / Re: Есть ТЗ и формализация требований заказчика, укажите на ошибки

« : 16 Мая 2017, 23:47:15 »

Не ясно, зачем два документа.
Формализация требований, как название процесса или его результат, должна завершаться в первом случае или являться во втором именно техническим заданием. Зачем плодить сущности?
Если [Формализация требований] - это документ, полученный в результате интервьюирования, и это хочется указать, то это скорее Протокол встречи.

Вообще, ваш материал по объему и содержанию больше соответствует Постановке задачи по ГОСТ 19, на ТЗ объективно не тянет.