151

Управление Проектом / Re: Что такое план? Академическое определение

« : 22 Марта 2013, 16:22:59 »

Похоже, вы говорите о фазах 3 и 4 проектного цикла:

1. Исследование
2. Анализ
3. Синтез (проектирование)
4. Планирование
5. Реализация

И все-таки должно быть какое-то понятие, объединяющее эти фазы.

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

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

Может быть: проектирование?

152

Управление Проектом / Re: Что такое план? Академическое определение

« : 22 Марта 2013, 11:23:55 »

Раньше (до этого топика) я понимал "план" и "планирование" в более широком смысле.
Под "планированием" я понимал весь "умственный" процесс, который начинается с обдумывания и постановки цели и заканчивается разработкой подробной модели решения, и который предшествует исполнению намеченной цели
А "план" - это был для меня совокупность результатов этого процесса (требования, модели, деревья текущей реальности, список задач, ТЗ и прочее).

Если сузить понятие "плана" до "План - есть совокупность конечных и промежуточных состояний, описанных в терминах достижимости.",
как тогда назвать весь описанный выше процесс, и всю совокупность его результатов, в которых фиксируются: цели, требования, варианты решений, выбранное решение, проект и модель решения...?

153

Управление Проектом / Re: Что такое план? Академическое определение

« : 22 Марта 2013, 10:47:46 »

2. Влад Балин http://gaperton.livejournal.com . Например: http://gaperton.livejournal.com/16087.html http://gaperton.livejournal.com/57204.html  http://gaperton.livejournal.com/49867.html http://gaperton.livejournal.com/37721.html http://gaperton.livejournal.com/33978.html http://gaperton.livejournal.com/47983.html http://gaperton.livejournal.com/30325.html и т.д.

Впечатляет.
А почему Gaperton сейчас этот блог забросил? Новых сообщений нету с  2012.07.04.

154

Теория моделирования и нотации / Re: Декомпозиция в Flying Logic при моделировании причинно-следственных связей

« : 22 Марта 2013, 02:05:58 »

Как использовать шаблоны?
Открываю шаблон - все пусто

155

Теория моделирования и нотации / Re: Моделирование связей между сущностями "цель - задача - средство решения"

« : 21 Марта 2013, 17:38:28 »

Перед тем как думать дальше, изучите остальные диаграммы Голдратта. "цель-задача-средство" это завершение анализа. Начало - "Дерево текущей реальности". Те же "причинно-следственные связи". Положите на изучение 3-5 лет и вперед.

Итак, за это время мной сделано следующее.
1) Прочитал:
- Детмер У. Теория ограничений Голдратта.
- Голдратт М.Э., Кокс Д. Цель.
2) Установил Flying Logic, и создал несколько диаграмм ДТР.

Выводы: действительно, очень помогает для анализа проблемы и выработки решения.
Но появился вопрос по декомпозиции диаграммы ДТР.
Лучше сделаю новую тему:
" Декомпозиция в Flying Logic при моделировании причинно-следственных связей" (http://www.uml2.ru/forum/index.php?topic=5354.0)

156

Теория моделирования и нотации / Декомпозиция в Flying Logic при моделировании причинно-следственных связей

« : 21 Марта 2013, 17:36:44 »

Этот вопрос навеян по результатам общения в теме: http://www.uml2.ru/forum/index.php?topic=5307.0

Вопрос такой.

При построении диаграммы ДТР в Flying Logic мне не хватало декомпозиции: количество элементов на диаграмме получилось очень большим.
Было бы удобно, если бы можно было построить ДТР в виде нескольких взаимосвязанных диаграмм, соответствующих разным уровням абстракции рассматриваемой проблемы.

Может быть это можно как-то сделать в Flying Logic?
Или какой-нибудь способ разрешения сложности ДТР посоветуете?

157

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 21 Марта 2013, 11:19:14 »

Тема ушла в другую сторону из-за моей фразы:

…
А в компетентности программистов, которые не хотят или не могут изучать UML, я бы усомнился
…

По справедливости, я был не прав. 
Denis Beskov, прошу меня извинить, в дальнейшем я постараюсь не говорить таких легкомысленных фраз.
Подключайтесь к обсуждению других моих тем.

158

Управление Проектом / Как правильно доработать СДР? Какой применить способ декомпозиции к новой СДР?

« : 21 Марта 2013, 10:56:37 »

Суть проблемы в том, что мне не совсем понятно как внести изменения в существующую структуру декомпозиции работ (составлена в MS Project 2010), и передать смысл этих изменений.
При добавление новых работ для реализации новой функциональности ПО в существующую СДР не отражается общее назначение этих работ.

Подробности:
Выполняется проект по разработке ПО.
Проект, вернее СДР, составлен по принципу "конечного продукта" и его составных частей, т. е. разрабатываемое ПО разделено на "подсистемы". Эти подсистемы в совокупности выполняют требуемые функции.
В общем СДР выглядит так:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3.
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.

Большая часть проекта уже выполнена, и сейчас решили добавить в разрабатываемое ПО еще одну функцию. Причем, хотим отследить ход разработки этой функциональности.
Например, чтобы эта функциональность была реализована, необходимо доработать подсистему 1 (создать новый элемент 1.4), подсистему 2 (доработать элемент 2.3), и подсистему 3 (создать элемент 3.4).
Список работ:
    - создать элемент 1.4
    - изменить элемент 2.3
    - создать элемент 3.4.
После добавления этих работ в СДР, сохраняя принцип построения СДР по конечному продукту, мы получим следующую СДР:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
    1.4. Элемент 1.4.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3. (изменение)
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.
    3.4. Элемент 3.4.

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

Можно доработать СДР так: создать новый пункт (4) и собрать работы для реализации новой функциональности в этот пункт:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3.
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.
4. Новая функциональность
    1.4. Элемент 1.4.
    2.3. Элемент 2.3. (изменение)
    3.4. Элемент 3.4.
Но так я считаю тоже будет неправильно. Так как теперь СДР составлена путем смешения разных подходов.

Как же правильно построить СДР, чтобы совместить и подход по результату и функциональный подход?
Для поиска ответа я даже для себя перевел документ PMI Practice Standard for WBS. 2nd edition. Однако четкого ответа так и не нашел. Там сказано, что можно строить и так, и так. Но как это совместить - не ясно.

Дайте пожалуйста какие-нибудь советы.

159

Управление Проектом / Re: Что такое план? Академическое определение

« : 20 Марта 2013, 11:58:36 »

Мне кажется, здесь http://dic.academic.ru/dic.nsf/enc3p/235190 или http://ru.wiktionary.org/wiki/%EF%EB%E0%ED, все представлено достаточно академично

Эти определения я читал раньше.
Но они по смыслу расходятся с определением в теме:
"План - есть совокупность конечных и промежуточных состояний, описанных в терминах достижимости."
И далее: Как только вы написали действие вместо результата, все - это более не план.
С таким подходом я встречаюсь впервые.

Мне интересно, как SALar обосновывает эти определения и на каких источниках основывается.

160

Управление Проектом / Что такое план? Академическое определение

« : 17 Марта 2013, 02:14:25 »

Наткнулся на тему, в которой было такое сообщение:

План не может содержать действий и/или исполнителей и/или трудоемкостей.

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

В своем время я сам долго искал определение плана для диплома, но так и не нашел определения, с которым был бы согласен на 100%.
Скажите пожалуйста:
1) источник, откуда вы взяли это определение
2) как по-вашему будет называться последовательность действий для достижения результата?

161

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 14 Февраля 2013, 14:40:54 »

Что вы неправильно понимаете место UML в индустрии, только и всего. Впрочем, как и многие другие люди, одураченные обилием книг с заголовком, включающим этом слово, в книжных магазинах. С тем же успехом можно заменить названия этих книг на «В поисках вечного двигателя», «Как я изобрел вечный двигатель», «Почему так мало людей используют этот прекрасный вечный двигатель?», «В поисках святого грааля», «24 способа применения святого грааля».

С одной но существенной разницей: вечного двигателя никто не видел, он не существует, и не решает никаких насущных проблем.

А теория относительности существует. Она кстати неидеальна. Но ее признают не потому что у нее красивое название. Просто вместо нее нету другой теории, которая бы позволяла описать наблюдаемые явления, и решать конкретные проблемы.

Также и с UML. Конечно, его заслуга не в красивых заголовках книг. А в том, что он позволяет решать конкретные проблемы, пусть и в достаточно ограниченной области деятельности.
Место UML понятно - моделирование.
Вы можете назвать другой инструмент, позволяющий описать модель программной системы, в виде взаимосвязанных диаграмм статических объектов системы и их динамического поведения?

162

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 14 Февраля 2013, 09:26:09 »

Я не видел, что был какой-то вопрос, и что он был как-то решён.

Я видел, что вы написали критическое замечание по поводу компетенций людей, с которыми никак не знакомы.
Я знаком.

Поэтому и пишу.

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

и еще вопрос.
что вы скажете о ... например, физике, который бы вам сейчас сказал:
"я про теорию относительности слышать не хочу, объясните мне что происходит в ядрах атомов на пальцах - при помощи классической механики"?
даже если этот физик вам знаком?

163

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 13 Февраля 2013, 18:06:49 »

А я всё к тому, какое отношение имеет усомнился или не усомнился ли анонимный es3000 в чьей-то там компетентности, к теме дискуссии?

Так вроде вопрос с компетентностью еще в начале был закрыт.
А тут двумя постами выше вы опять его вроде подняли.
Мне пришлось защищаться объясняться

164

Теория моделирования и нотации / Re: Моделирование связей между сущностями "цель - задача - средство решения"

« : 13 Февраля 2013, 18:00:41 »

2es3000   Вам определенно стоит сходить:

RT Pls: Рассказ и мастер-класс про деревья текущей реальности (21 февраля, Москва, Mail.Ru)
http://cartmendum.livejournal.com/119785.html

я не из Москвы, живу в Пскове

165

Теория моделирования и нотации / Re: Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 13 Февраля 2013, 17:50:01 »

я об этой фразе

а-а-а.
Ну тогда насчет инженеров гугла есть два варианта:

1) Они изучали UML, по крайней мере ознакомились с ним, но по каким-то наверное веским причинам, отказались от его использования. Тогда все нормально

2) Они не знакомились с UML.
В этом случае я свою фразу "...в компетентности программистов, которые не хотят или не могут изучать UML, я бы усомнился..." подтверждаю.
Ведь это еще студентам в институте преподают, что для построения модели одного вида схем или диаграмм недостаточно.
Следовательно, граф зависимостей, используемый инженерами гугла явно недостаточен для полного моделирования разрабатываемого ими ПО.