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

×


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

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


Сообщения - SALar

Страницы: « 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 »
31
Посмотрите книгу Андрея Орлова "Записки автоматизатора". Крайне, крайне рекомендую.

32
34.602 Можно писать чтобы тендеры выигрывать, а можно, чтобы работало.
Если, чтоб работало, то в ТЗ я бы записал требование к должностным инструкциям. Что они должны быть созданы в рамках проекта. Перечислить какие инструкции должны быть и т.д. (желательно).

33
Если система, то лучше ГОСТ 34. ГОСТ не регламентирует состав документа, а рекомендует. Так что пункты там могут быть любые. Правда госзаказчики об этом не знают, так как ГОСТ-ы не читали.
Другие способы и более хорошие есть. Мне нравится модель Щедровицкого, но это мне.

Для описания процесса опишите:
* Продукт (Выход)
* Материал (Вход)
* Средства преобразования
* Порядок преобразования
* Нормы деятельности
* Навыки персонала

PS. Как раз сейчас я тренинг по описанию процессов веду...

34
Тестировщикам,видимо будут интересны "Описание ключевых процессов тестирования" и "Создание плана обеспечения и контроля защищенности ПО", а менеджерам - остальные два.
Аналитикам - "быстрые проверки управленческих решений"

Ссылка: https://sergey-martynenko.timepad.ru/events/
Материал крайне редкий. Если вообще существует.

35
Георгий Савельев. Бизнес-анализ в консалтинговом проекте по развитию продаж булочного комбината: https://www.youtube.com/watch?v=LKxvBG5_wQ0


Очень рекомендую.

36
Sparx / Re: Как освоить Enterprise Architect за месяц?
« : 28 Апреля 2017, 11:51:39 »
Порог вхождения для UML.
В одной из фирм, где я работал всех разработчиков (программистов, менеджеров, тестировщиков) отправили на тренинг по UML. Недельный. 40 часов.
Для того, чтобы осмысленно пользоваться этой нотацией, 40 часов тренинга - недостаточно. Потом нужно "набивать руку".

Цитировать
Цитата: L-shev от 13 Апреля 2017, 17:28:09
Цитировать
Есть предположение, что если все сотрудники будут работать в единой системе, то это всем выгодней и удобней.
Есть предположение, что вы даже не представляете, в какую копеечку это влетит НИИ, прежде чем станет (если когда-нибудь станет) выгоднее и удобней. И дело совсем не в лицензиях АА, которые на худой конец можно "приобрести" в какой-нибудь ознакомительной торрент-версии.

У этой медали есть несколько сторон.
1. Деминг сказал: "Все дело в уменьшении вариаций". Он прав. Единый стиль работы -> уменьшение вариаций -> выгода.
2. Роберт Гласс сказал: "В разработке ПО возможности улучшений, за счет инструментов практически выбраны. Маловероятно, что внедрение какого либо инструмента даст выигрыш более процента". Ну, или немного не так сказал.

Если вы внедрите единый стиль написания документации - получите огромный выигрыш.  Внедрите инструмент - не получите ничего.

Поэтому. Пользуйтесь пока бесплатным draw.io Когда поставите процесс - можно выбирать инструмент.
Все, всегда пытаются сделать наоборот. С известным заранее, неизбежно печальным результатом ( http://lurkmore.to/%D0%AD%D0%BF%D0%B8%D0%BA_%D1%84%D0%B5%D0%B9%D0%BB ).

Цитировать
разруха не в клозетах, а в головах

37
Sparx / Re: Как освоить Enterprise Architect за месяц?
« : 25 Апреля 2017, 10:54:10 »
Может поможет, может нет.

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


2.
Цитировать
Гарри с грустью подумал о Дартмутском семинаре 1956-го года, первой в истории конференции по вопросам искусственного интеллекта. В качестве ключевых вопросов участники выделили: понимание языка, самообучение и самосовершенствование компьютеров. Они абсолютно серьёзно предполагали, что десять ученых смогут достичь существенных результатов по данным вопросам, если будут работать вместе в течение двух месяцев.

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

Гарри начал понимать, как себя должен был чувствовать тот аспирант.

Похоже, вы положении того аспиранта.

38
Кстати. Термин agile был в моде лед 10 назад. Потом было модно говорить Канбан. Сейчас модно говорит девопс.
С каждой итерацией все становится хуже и хуже.

39
Решил вернуться к теме...

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

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

Люксофт реализовал это в экселе.

40
Trackstudio.
Отличная фасетная декомпозиция.

41
Я умею писать техническое задание для водопадного метода -  там сразу всё очень подробно пишется.
А когда планируется agile метод разработки, то как будет выглядеть техническое задание -  просто список названий пользовательских историй(я имею ввиду ту часть технического задания, где в водопадном методе  описываются "Системные функции", а именно "Функциональные требования")?
1. ТЗ для agile пишется точно так же ка для не agile.
2. RUP и MSF это agile? Ваше определение.
3. А что такое agile? Я собираю коллекцию определений. Они довольно забавны. Лучшее было: "Хренак, хренак и в продакшен - это agile!".
4. А что водопад существует?!
5. Кроме того, водопад ничем не противоречит agile. Внезапно. Но не все это знают.

42
Кстати. Главное не уметь писать, а уметь верифицировать требования. А вот это, насколько я знаю, нет нигде, кроме как на моем тренинге. Я думаю как тестировщик и верификация для меня всегда стояла на первом месте. Но из-за отсутствия литературы мне понадобилось очень много лет, чтобы научиться. Коберн верификации уделяет непозволительно мало внимания. А у остальных этого, насколько я знаю, просто ничего нет.

За много лет конференций мне известны три доклада по верификации. Теперь появился четвертый: http://analystdays.ru/ru/talk/45151

43
Поделитесь стандартным путем достижения до сценариев использования, я понимаю что для каждого программного решения свои дороги. Чтобы хоть от чего нибудь отталкиваться. А то два месяца потратил на прочтение книг, а ясной картины до сих пор не могу увидеть.
Для примера можно взять ИС отдел кадров.
Сходить на тренинг.
Один день вместо двух месяцев. На выходе очень хороший результат.
Впрочем, если у вас времени вагон, то тренинг не ваш метод.

44
В чем фишка? Смотрю, ты эту фразу как мантру повторяешь во многих местах?
Это очень неожиданный подход. Вот придет человек в дырявых носках, станет ему неудобно и он уйдет.
Лучше предупредить заранее. И лучше несколько раз.

PS. Несмотря на все предупреждения несколько человек ошиблись. Там есть гостевые тапочки, чтобы дойти до туалета. А они в них в зал поперлись.

Страницы: « 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 »