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

Сейчас в разделе "1. Методологии" смешаны методологии организации процесса разработки (RUP, XP, etc) и методологии отдельной его дисциплины - проектирования, причём первые почему-то названы методологиями проектирования. Возможно, это имеет отношение к ведущейся где-то тут дискуссии о смысле и понимании слова "проектирование". Кроме того, здесь же находится раздел, по дисциплине, методологии вообще не имеющей - а именно, сбору требований. Есть отдельные методы сбора, выявления, фиксации, организации и управления требований, методологии - нет.

Раздел "проектирование" имеет разделения по версии UML - не понимаю, какую практическую пользу это несёт. Имхо надо разделять по группам деятельности, по задачам.

А именно, чётко выделить 3 ключевые, в смысле системного анализа в ИС, дисциплины, которые активно применяют UML и не только, а именно:
А. Бизнес-Моделирование
Б. Требования
В. Проектирование

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

Вот и структура.

Б-А, Требования и ПРоектирование - ключевые разделы, которые стоит формировать в первую очередь, остальное - по мере роста.

Структура мне нравится, остается ее сделать, нужно волевое решение администратора и владельца, и назначить исполнителя:-)) Я чур пас

В принципе структура и мне нравится, только:
1. Инструменты надо выделеить в отдельный синий раздел, т.к. они пересекаются очень
2. Зеленые разделы видимо не надо добавлять, у нас не так много материала или хотя бы объеденить некоторые зеленые разделы.
4. И в каждый синий раздел надо добавить зел. раздел - Примеры

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

В принципе структура и мне нравится, только:
1. Инструменты надо выделеить в отдельный синий раздел, т.к. они пересекаются очень

Они пересекаются только между Бизнес-моделированием и Проектированием, и то главным образом только поддерживающие OO-подход, инструменты SADT и ARIS я бы в наше время на Проектирование (в частности, внутреннего устройства) ИС не распространял.

У Тестирования есть свои специализированные инструменты у Требований - тоже, у Реализации - тем более. У процессов разработки есть ALM.

Т.е предлагается подход такой - если некий узел потенциально может относиться к нескольким категориям, то помещаем его в ту, которую он изначально, исторически и большую часть времени относился. Таким образом UML-инструменты будут находиться в Проектировании. В качестве лакмусовой бумажки предлагаю такой тест - много ли вы знаете BPR-проектов для не-IT структур, в которых моделирование велось бы в UML с использованием соотв. инструментов? (Это кстати, хорошая тема для разговора - выбор нотации моделирования БП)

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

В принципе готов.

Ну хорошо, у меня только один вопрос:
А вот куда пойдет книга Коберна?

З.Ы. Ну отлично тогда, права будут, я или Эдуард сделаем.

Коберна, ессно, в требования.

Денис, ВЫ администратор. Пользуйтесь своими правами с достоинством и осторожностью:-))