Александр Филонов пишет: "Про иглу" мы недавно рассматривали здесь в другой теме. Выяснилось, что виноват точильщик, которого сократили, потому что игла тупая и когда тупая - ломается.

Боже, их еще и точат. Надо было знакомой швее позвонить, прежде чем писать

Александр Филонов пишет: Выявлены кем? "Простым рабочим" или "аналитиком"?
PS Не забудьте Ваш тезис о ДИ предназначен только для решения "простых задач".

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

Александр пишет: Помню. ДИ используется для предварительного анализа. Рабочий на этом может ограничится, а аналитик после предварительного анализа пойдет вглубь проблемы.

Т.е. мы имеем дело с процессом, где должно быть отсечение "задач" от "проблем"?

Кто будет отсекать - "рабочий" или "аналитик"?

Как определить было (дефект, происшествие) - "задачей" или "проблемой"?

Давайте определяться с дефинициями, чем отличается " проблема " от "простой задачи" ( задачи )?

Андрей Сазонов пишет: Боже, их еще и точат. Надо было знакомой швее позвонить, прежде чем писать

А як же шь.

Александр пишет: Для этого случая есть классической решение! С проблемой большого количества ошибок разработчики ПО столкнулись в 60 годах прошлого века. Анализ показал, что проблема в том, что отсутствует технология разработки требований. В результате были разработаны десятки таких технологий, однако в настоящее время стандартом стала методология структурного анализа и проектирования (SADT), которая сейчас обозначается IDEF.
А теперь ответьте на вопрос - в каких фирмах по разработке ПО используют этот стандарт? Нет, у нас идут по другому пути - создают отделы тестирования, которые ищут ошибки в разработанных программах. А ведь идея структурного программирования ставила своей целью написание ошибок, в которых не будет ошибок.

Да как сказать. SADT, IDEF - это моделирование. И сейчас моделируют при составлении требований. Например UML или story mapping используют. Я предложил не моделировать, а сразу экспериментировать. Моделирование конечно хорошо, но составление такой модели, по которой будут видны все проблемы ПО, эквивалентно написанию самого ПО за срокам и затратам. Да и при переходе "модель -> план" можно что-то потерять, как и при любом последующем переходе.

У народа есть мысли как работать с подобным, вот только никто не сподобился сделать инструмент еще пока. Ну да ладно, на софт не будем отвлекаться больше. Уйдем в сторону...

Александр Филонов пишет: Давайте определяться с дефинициями, чем отличается "проблема" от "простой задачи" (задачи)?

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

Андрей Сазонов пишет: Я предложил не моделировать, а сразу экспериментировать.

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

Александр пишет:

Александр Филонов пишет: Давайте определяться с дефинициями, чем отличается "проблема" от "простой задачи" (задачи)?

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

Александр, в этом документе нет определения "задачи" или "простой задачи".

Что брать за основу?

Александр Филонов пишет: Александр, в этом документе нет определения "задачи" или "простой задачи".

Простая задача это та, которую может решить сам персонал, без привлечения дополнительных ресурсов. Сложная задача - та, которую могут решить специалисты. Если средствами персонала проблема не решается, то она передается специалистам. Вроде, другого ответа трудно придумать. А собственно, я не очень понимаю что вы имеет ввиду, все время возвращаясь к этому вопросу.

Александр пишет: А собственно, я не очень понимаю что вы имеет ввиду, все время возвращаясь к этому вопросу.

А то, что если решение "проблемы" известно - то это не ПРОБЛЕМА (по определению).

Может ли быть персонал виноват, если он не знал как решить ПРОБЛЕМУ и допустил ошибку?