Форум Сообщества Аналитиков
Обсуждения => О Сайте и Форуме => Тема начата: Denis Beskov от 11 Января 2007, 16:25:14
-
Я бы предложил не создавать пустые папки в хранилище - как будет книга, материал - тогда уже создавать.
Сейчас в разделе "1. Методологии" смешаны методологии организации процесса разработки (RUP, XP, etc) и методологии отдельной его дисциплины - проектирования, причём первые почему-то названы методологиями проектирования. Возможно, это имеет отношение к ведущейся где-то тут дискуссии о смысле и понимании слова "проектирование". Кроме того, здесь же находится раздел, по дисциплине, методологии вообще не имеющей - а именно, сбору требований. Есть отдельные методы сбора, выявления, фиксации, организации и управления требований, методологии - нет.
Раздел "проектирование" имеет разделения по версии UML - не понимаю, какую практическую пользу это несёт. Имхо надо разделять по группам деятельности, по задачам.
А именно, чётко выделить 3 ключевые, в смысле системного анализа в ИС, дисциплины, которые активно применяют UML и не только, а именно:
А. Бизнес-Моделирование
Б. Требования
В. Проектирование
Далее предлагаю своё видение возможной организации, причём особо подчеркну, что под каждый узел у меня есть материал, который я могу выложить.
-
Вот и структура.
Б-А, Требования и ПРоектирование - ключевые разделы, которые стоит формировать в первую очередь, остальное - по мере роста.
-
Структура мне нравится, остается ее сделать, нужно волевое решение администратора и владельца, и назначить исполнителя:-)) Я чур пас
-
В принципе структура и мне нравится, только:
1. Инструменты надо выделеить в отдельный синий раздел, т.к. они пересекаются очень
2. Зеленые разделы видимо не надо добавлять, у нас не так много материала или хотя бы объеденить некоторые зеленые разделы.
4. И в каждый синий раздел надо добавить зел. раздел - Примеры
Если, Денис, ты готов сделать этот не легкий труд с пересозданием структуры, пересортировки имеющегося материала (чтобы ничего из имющегося не потерялось), то можно те дать адинские права и начать все это переделывать....
-
В принципе структура и мне нравится, только:
1. Инструменты надо выделеить в отдельный синий раздел, т.к. они пересекаются очень
Они пересекаются только между Бизнес-моделированием и Проектированием, и то главным образом только поддерживающие OO-подход, инструменты SADT и ARIS я бы в наше время на Проектирование (в частности, внутреннего устройства) ИС не распространял.
У Тестирования есть свои специализированные инструменты у Требований - тоже, у Реализации - тем более. У процессов разработки есть ALM.
Т.е предлагается подход такой - если некий узел потенциально может относиться к нескольким категориям, то помещаем его в ту, которую он изначально, исторически и большую часть времени относился. Таким образом UML-инструменты будут находиться в Проектировании. В качестве лакмусовой бумажки предлагаю такой тест - много ли вы знаете BPR-проектов для не-IT структур, в которых моделирование велось бы в UML с использованием соотв. инструментов? (Это кстати, хорошая тема для разговора - выбор нотации моделирования БП)
Если, Денис, ты готов сделать этот не легкий труд с пересозданием структуры, пересортировки имеющегося материала (чтобы ничего из имющегося не потерялось), то можно те дать адинские права и начать все это переделывать....
В принципе готов.
-
Ну хорошо, у меня только один вопрос:
А вот куда пойдет книга Коберна?
З.Ы. Ну отлично тогда, права будут, я или Эдуард сделаем.
-
Коберна, ессно, в требования.
-
Денис, ВЫ администратор. Пользуйтесь своими правами с достоинством и осторожностью:-))