Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Леонид

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 »
1
Вопрос безусловно верный. Я и сам им задаюсь постоянно, что же понимать по этим незатейливым термином: инструментальное средство ИС?
Более того, а что есть такое инструмент, и как понимать, что есть средство?

Делов-то! Перечислить жизнеспособные варианты. Взять за инструмент любую детскую считалочку, выбрать с ее помощью один вариант и объявить его ортодоксальным.

Некоторые замечательные люди в своих учебных пособиях пишут:

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

Т.е. если сделать замену слова программные на ИС, то все равно ИС ИС  - это ПО, предназначенное для использования в ходе проектирования, разработки и сопровождения ИС. Вот так вот.

Нельзя. В этом определении "программные" можно заменить на "аппаратные", "организационные", "методические" и т.п. из следующего определения, но никак не на "ИС", "станки" и "выпечку".

Определение вполне себе годное. Согласно ему, те же офисные продукты МС вполне себе предназначены (хотя бы потому, что в Визио есть наборы объектов для традиционно-аналитического рукожопства).

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

А вот это вообще заход с козырей. Не убавить, ни прибавить. Так и есть (на мой непритязательный вкус).

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

Позволю себе не согласиться. Далеко не при любом раскладе. В моей практике было сильно больше одного случая, когда ИС прямо со страпелей уходили в "Фонд алгоритмов и программ". Чаще всего, правда, со "справкой" об успешном внедрении.

2
Ну почему же. Текстовый редактор - его назначение составлять тексты, форматировать их. представлять в нужном виде и т.п.
Как могут быть использованы текстовые редакторы, является ли он инструментальным средством ИС? Отчет ведь весьма широк.

С другой стороны какой-нибудь редактор BPMN моделей, ну сложно себе представить, что вы будете его использовать, чтобы писать вдохновенные любовные стихи, верно ведь?

Верно.
Однако тут можно плясать от определений. Что такое инструментальное средство ИС? Инструмент, предназначенный исключительно для разработки ИС, или инструмент, который используется в разработке ИС (и без которого эту разработку представить сложно)? Можно также взвесить "вклад" того или иного инструмента. Если человекочасы, проведенные сотрудниками в текстовых редакторах на порядок-другой больше человекочасов, проведенных в редакторе BPMN, то что из них больший инструмент?

Кроме того, есть инструменты, из которых можно сварить не одну только кашу. Вот, к примеру, Эксель. Одна из контор в моей практике прекрасно пользовалась оным для: 1) управления проектом с задачами и ответственными, трудозатратами, планированием и т.п. фичами и 2) трекинга требований и задач. И не имела ни МС Проджекта, ни Джиры.
Об этом студентам тоже неплохо было бы рассказывать.

3
Да, конечно и таких инструментов не мало. Но не думаю, что о них (кроме как упоминания класса и некоторых представителей) стоит упоминать.

Тогда будет почти цэ: "Экзотические инструменты и где их применяют".

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

Можно, но уж очень напоминает костыли.

4
Может быть, хотя процессы ЖЦ как признак классификации удобнее
1 еще раз прорабатываются все этапы ЖЦ ИС
2 инструменты рассматриваются в привязке с этими этапами

Хм... Ну, вполне возможно. Дело вкуса, в конце концов. Просто бОльшая часть инструментов используется более чем на одном этапе. Тот же МС Ворд - он вообще везде и всегда, а трекеры - по вкусу, хвостом уходя глубоко в эксплуатацию, а носом утыкаясь иногда даже в предпроектную стадию (но чаще все же с началом разработки кода).

Можно, наверное, диаграмму полезности(ну или применимости) инструментов нарисовать вдоль ЖЦ.

Можно.  Если скажите к кому обратиться, обращусь :) Но какой смысл? Прошлое изменить нельзя, будущее для них уже прошлое.

Да я несколько не спец в персоналиях из системы образования, не моя область. Но если не особо интересно (и пользы от такого знания не предвидится) - то да, вероятно нет смысла суетиться.

5
Вы, наверное, совсем не понимаете как устроена наша система образования. Не так-то просто изменить учебный план. Потому обычно, план стабилен, а вот содержательная часть меняется, но меняется субъективно, исходя из интересов, возможностей преподавателя, кафедры в целом.

Я ровно об этом. Чуть выше было сказано, что есть другие спецдисциплины, в рамках которых рассматриваются отдельные инструменты. Они даются более-менее основательно. А все остальное полезное - в общую обзорную кучу под названием "Инструментальные средства..."

6
Если Вы почитаете дискуссию. то увидите, что я тоже задаюсь этим же вопросом. Поскольку получить ответ от того, кто придумал стандарт и включил в него это предмет, не суждено, то остается только гадать. И поскольку предмет базовый(исключить его нельзя) приходится думать о его пользе :)

Ну, я там больше про ЖЦ вычитал... И лично по мне, ставить во главу угла ЖЦ столь же полезно, сколь и подход имени инвентаризации хозмага. Ни в чем особо не выигрывает.

А кстати, почему нельзя обратиться за разъяснением к авторам? Минобр (или кто там творец) на письменные обращения разве не отвечает? Понятно, что сейчас уже несколько поздно, но на будущее... да и так,  в целом для развития.

7
Естественно компетенции вуза всегда будут в ограниченном наборе инструментов в силу куче объективных и субъективных причин.

Я немного не об этом (компетенции любого отдельно взятого субъекта всегда ограничены в силу названных причин). Я про то, что "вот тут мы знаем и даем хорошо, а вот про это будет отдельный обзорный курс".

8
Оболтусы ведь приходят на этот предмет не из вакуума, и до этого они сдают, делают огромное количество практических задания использую большое число инструментов, и на каждой той спецдисциплине всегда присутствует в лекциях или в лабах небольшой раздел обзора инструментов

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

Причем ранее 15 лет отсутствия дисциплины по инструментальным средствам никак не мешало студентам это делать. Именно этот аспект мы с НЛО и обсуждали. Он на инопланетном, я на русском.

Тогда не совсем ясна ценность этой дисциплины. Я понимаю, если бы у Вуза имелись некие компетенции в ограниченном наборе инструментов, которыми учили пользоваться оболтусов. А остальные популярные рассматривали бы обзорно в рамках такой вот дисциплины.

Если же и студенты подкованы, и выбрать есть из чего, то единственный вопрос (у меня, как у практика) - зачем?

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

9
В начале цикла обсуждения, НЛО высказал мысль, что пользы от такого обзора немного, и я с его мыслю согласен. Ну типа беглого обзора всего, что есть из инструментария в строительно-ремонтном магазине. Вот в этом направлении мы и обсуждаем.

Да, это я заметил. Академической пользы, наверное, действительно немного. Но вот практическая, которая поможет в подготовке к реальной работе и составлению резюме, определенно имеется (хоть и не решает).

лекционный материал в целом так и выстроен, но это так скучно читать 17 лекций, делая обзор инструментов большую часть которых ты и в глаза не видел.

Читать самому не доводилось, но склонен согласиться. Более того, слабо представляю, кто кроме практически-ориентированного "зубра" сможет прочесть такое на основании собственного опыта (я, например, не возьмусь). А "зубр" с подобным опытом может прочесть и что-то более фундаментально полезное.

Тем не менее, на мой взгляд, оболтусам было бы полезно ориентироваться в инструментарии хоть чуть-чуть, чтобы не думали, что молотком роют канавы, а лопатой закручивают саморезы. (подобные заявления на собеседованиях слышал неоднократно)

10
Коллеги, может я с кавалерийского наскока не понял всю глубину глубин, но почему бы просто не сделать обзорный курс разного инструментария, который используется (или может использоваться) с момента задумки до момента списания АИС с "боевого дежурства"?

Ну например (очень-очень грубо)
1. Для концептуальных заметок, фиксации мыслей - блокнот с ручкой, блокнот виндовый, ворд и т.п.
2. Для документирования систем - Либроофис, МС Офис, (что-то еще)
3. Для подготовки схем и диаграмм - Визио, Энтерпрайз Архитект, Пауэр Дизайнер.
4. Для реверса БД - Пауэр Дизайнер
5. Для тестирования сервисов - Соап Юай
6. Для кодинга - всяческие оболочки и т.п. (несколько штук)
7. Для багтрекинга - Джира, Редмайн и т.п.
7. Для мониторинга работающих систем - ИБМ Максима и т.п.
8. Для вывода из эксплуатации - программы-стиратели, размагничиватели носителей и т.п.

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

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

11
...и не стоит ждать что по каждому такому вопросу сотрудник будет штудировать 80 страниц текста.

В этом случае применение специфических нотаций только повредит. Ибо не стоит ждать, что сотрудник ринется их изучать.
Блок-схема - вполне неплохое решение, на мой непритязательный вкус.

12
Для всех / Re: Корреляция
« : 24 Июля 2017, 16:18:06 »
Математиками их называют. Постоянно пытаются найти корреляцию во всём, где сказали искать или где самим хочется. Иногда находят, иногда нет.

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

13
По вашему мнению с помощью какого вида диаграмм или нотаций лучше решить эту задачу?

Диаграммы и нотации тут ни при чем от слова совсем. Хочется графически изобразить - рисуем обычную структуру из прямоугольников и линий.

В озвученной постановке задача про классификацию. Перечисленные документы - типичная "Организационно-распорядительная документация" (ОРД). Есть ГОСТ Р 7.0.97-2016 про ее оформление, но он в классификации для увязки с уровнями управления не сильно поможет.

Копать, на мой взгляд, нужно в сторону предметной области делопроизводства, нормоконтроля и прочих архивов. В этих областях собаку съели на назначении, сходствах и различиях такого рода документов. Ну и некоторые управленческие квалификации понадобится.

14
Речь как я понимаю не идет о анкетировании, собеседовании. опросах и т.д.

А о чем тогда идет?

15
Так очень кратко можно представить работу по методологии RUP? верны ли мои догадки?

Так очень кратно можно представить работу по любой итерационной методологии.

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 »