Сообщений в теме: 40

[Dmitry_NJ]

Хотя, как Вы знаете, существует и другая точка зрения, например, в  Mercury WinRunner and Test Director , где программирование рассматривается как кодирование и отдельно выделяется этапы отладки и анализа. Сейчас я как раз работаю с этой системой, отсюда и возникшая оперативная ошибка.

Что-то я не совсем помимаю вашу мысль насчет каких-то особенностей в программировании с использованием WR. Чем программирование в WR принципиально отличается от программирования, например, в Visual Studio? Кроме того, что не создается исполняемый файл?

[Dmitry_NJ]

В тоже время в ней можно встретить некоторые довольно странные терминологические моменты (во всяком случае в версии 6, с которой я работаю). Например, к test planning они относят разработку не только дизайна тестов (тест-плана и пошаговой детализации), но и программирование тестов. При этом сам термин программирование они, в основном, используют в исключительно узком смысле как «ручное» кодирование с использование языка TSL, отдельно выделяя recording, хотя это также является программированием, только другим методом.

Полагаю, что те, кто писал документацию, меньше всего заморачивались относительно терминологических нюансов вроде того, что считать ли recording методом программирования или чем-то отдельным. Это все лирика, о которой можно долго спорить, но которая имеет мало общего с тем, чтобы овладеть инструментом и начать его эффективно использовать, для чего собственно всякие user's guides и пишутся.

А вообще-то WinRunner 6 очень древняя версия, и я сильно сомневаюсь, что она вообще до сих пор поддерживается.

[barancev]

Согласно стандарту ISO/IEC 12207 процессы, связанные с ЖЦПО разделены на три группы:
· основные процессы;
· вспомогательные процессы;
· организационные процессы.

Исходя из этого ЖЦПО можно рассматривать как состоящий из основного цикла(работ, непосредственно связанных с созданием программ) и вспомогательных циклов(работ обеспечивающих завершённость основного процесса: документирование, тестирование и т.п.). Каждый такой дополнительный цикл являются смежным по отношению к основному, а их синхронизация осуществляется в, так называемых, milestone(вехах). Подробнее я это рассматриваю в своём курсе (тема 1.4.).

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

Я -- руководитель проекта по разработке ПО. И я Вам говорю, что модель, построенная на разделении процессов и синхронизации их в контрольных точках не работает в современных условиях на проектах такого масштаба, какими мне лично приходится обычно заниматься -- протяжённостью несколько месяцев и с штатом порядка 10 человек. Вот не работает и всё. Может это я такой тупой, но почему-то ни у кого, с кем я говорил, кто выполняет похожие по масштабу проекты, тоже не работает.

А какая же модель работает? Основанная на деятельностях и потоках, примерно так, как описывает RUP. Деятельности можно условно распределить по подпроцессам, которые позволяют получить более высокоуровневый взгляд на процесс в целом. Их можно также условно разделить по стадиям, которые суть не что иное, как учёт временного фактора -- ближе к началу или к концу обычно выполняется та или иная деятельность; какие деятельности обычно выполняются одновременно и параллельно.

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

Что касается самого термина «Жизненный цикл тестового обеспечения» то здесь я, увы, не оригинален. Многие англоязычные авторы в области тестирования так или иначе используют его. Например, в [ 3] это понятие так и называется Testware Life Cycle.

Это легко объяснимо -- как Вы сами сказали, это "авторы в области тестирования". Они намеренно и сознательно сужают тему и выделяют деятельности по тестированию из всех остальных, пытаясь рассматривать их хотя бы в частично изоляции. Вот и возникает Testware Lifecycle. По моему опыту, в реальных проектах так не бывает. Ну, может быть в очень больших и длинных проектах удаётся выделить, но мне не доводилось такого даже видеть, не то чтобы участвовать.

[Viktor]

Я -- руководитель проекта по разработке ПО. И я Вам говорю, что модель, построенная на разделении процессов и синхронизации их в контрольных точках не работает в современных условиях на проектах такого масштаба, какими мне лично приходится обычно заниматься -- протяжённостью несколько месяцев и с штатом порядка 10 человек. Вот не работает и всё. Может это я такой тупой, но почему-то ни у кого, с кем я говорил, кто выполняет похожие по масштабу проекты, тоже не работает.

А какая же модель работает? Основанная на деятельностях и потоках, примерно так, как описывает RUP. Деятельности можно условно распределить по подпроцессам, которые позволяют получить более высокоуровневый взгляд на процесс в целом. Их можно также условно разделить по стадиям, которые суть не что иное, как учёт временного фактора -- ближе к началу или к концу обычно выполняется та или иная деятельность; какие деятельности обычно выполняются одновременно и параллельно.

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

Подождите, Алексей, для участников поясните:
Разве process, thread, task, work, activity не синонимичны в RUPe?

В чем отличия процессной модели от модели RUP?

Разве есть противоречия между RUP и стандартом 12207?

Разве процессный подход не основополагающий принцип менеджмента качества?

Разве зачем (:)) управлять качеством это вопрос ?

[barancev]

Подождите, Алексей, для участников поясните:
Разве process, thread, task, work, activity не синонимичны в RUPe?

Поясняю цитатами из RUP.

Деятельность (activity)
An activity is something that a role does that provides a meaningful result in the context of the project. The activity has a clear purpose, usually expressed in terms of creating or updating some artifacts.

Поток (workflow)
A workflow is a sequence of activities that produces a result of observable value.

Подпроцесс (discipline)
A discipline is a collection of related activities that are related to a major 'area of concern' within the overall project. The grouping of activities into disciplines is mainly an aid to understanding the project from a 'traditional' waterfall perspective - typically, for example, it is more common to perform certain requirements activities in close coordination with analysis and design activities. Separating these activities into separate disciplines makes the activities easier to comprehend but more difficult to schedule.

Может быть, перевод последнего термина не очень удачный, но это самое лучшее из того, что мне встречалось.

Остальные упомянутые Вами термины (process, thread, task, work) в RUP не используются. Впрочем, термин "процесс" используется, но только для обозначения всего в целом, это THE process.

В чем отличия процессной модели от модели RUP?

Прочитайте внимательно приведённое выше определение подпроцесса (discipline), и если ответ не придёт, задайте вопрос ещё раз.

Разве есть противоречия между RUP и стандартом 12207?

Откуда я знаю? Пусть по этому поводу голова у IBM Rational болит, если это так важно :)

Разве  процессный подход  не основополагающий принцип менеджмента качества?

Насколько мне известно, нет, а что? Где это постулируется в качестве основополагающего принципа? В основу можно положить и другой принцип, если он работает.

Разве зачем управлять качеством это вопрос ?

Вообще-то я это вопрос не задавал. А Вы, кстати, знаете на него ответ? :)

[Viktor]

Ох и люблю я цитаты!

Остальные упомянутые Вами термины (process, thread, task, work) в RUP не используются.

Хорошо, отдаю Вам должное, я провокационно ввел первые три (process, thread, task)
(Они используются, но для других целей :), да?)
Поэтому, пойманный за руку, должен согласиться, что RUP не использует "процессный" подход
RUP использует какой-то другой подход, discipline-ный, что это значит надо будет как-нибудь обсудить :)

Насколько мне известно, нет, а что? Где это постулируется в качестве основополагающего принципа? В основу можно положить и другой принцип, если он работает.

Я всегда думал, почему это так трудно применить RUP в нашей конторе, внедрившей систему качества 9000, теперь мне ответ очевиден :) - ISO 9000 использует процессный подход как основополагающий в системе менеджмента качества.

Вообще-то я это вопрос не задавал.

Никаких претензий :)

А Вы, кстати, знаете на него ответ?

Так ведь ..., Э-ээ ...., Затем, что ..., А как иначе?
У меня весь офис (образно) увешан этими плакатами, я чихнуть не могу, попаду в очередное руководство или политику. Думаю, ответ уже где-то на подходе. :). А если вообще несерьезно, иногда очень удачно можно вставить: "А как же! Иван Васильевич! Менеджмент качества требует соблюдения этих процессов здесь, здесь и особенно здесь. Поэтому нет никакой возможности закончить данную работу в такие короткие сроки. Правда, можно попросить ребят напрячься, но это, сами понимаете, во что выливается!"

[barancev]

Остальные упомянутые Вами термины (process, thread, task, work) в RUP не используются.

Хорошо, отдаю Вам должное, я провокационно ввел первые три (process, thread, task)
(Они используются, но для других целей :), да?)

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

Поэтому, пойманный за руку, должен согласиться, что RUP не использует "процессный" подход
RUP использует какой-то другой подход, discipline-ный, что это значит надо будет как-нибудь обсудить :)

Я бы так не сказал. Обратите ещё раз внимание на то, что они пишут про discipline -- распределение деятельностей по подпроцессам чисто условное и сделано для "совместимости" с другими моделями процессов, в частности с водопадной моделью. То есть для простоты ориентирования в наборе деятельностей тем людям, которые привыкли к традиционному разбиению по "дисциплинам" -- разработка отдельно, тестирование отдельно, управление отдельно и т.д. (их там в RUP девять видов выделено, подпроцессов/дисциплин).

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

Я всегда думал, почему это так трудно применить RUP в нашей конторе, внедрившей систему качества 9000, теперь мне ответ очевиден :) - ISO 9000 использует процессный подход как основополагающий в системе менеджмента качества.

Любопытное наблюдение. Неужели это правда???

Интересно, кто-нибудь имеет данные о совместимости RUP с CMM? IBM Rational утверждает, что RUP не только не препятствует, но даже помогает достичь, по крайней мере уровней 2 и 3.

[Mike]

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют. Сертифицированы ли мы по 9000 не помню, но, кажется, да...

[Viktor]

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют.  Сертифицированы ли мы по 9000 не помню, но, кажется, да...

А у Вас процессы имеются?
ИСО 12207 соблюдаете?

[barancev]

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют. Сертифицированы ли мы по 9000 не помню, но, кажется, да...

Слава Богу!!! А то я уж испугался :)

[Viktor]

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют.  Сертифицированы ли мы по 9000 не помню, но, кажется, да...

Слава Богу!!! А то я уж испугался :)

Слушайте, ну я так не играю, шаблоны ... роли ..., я, например, реквизит использую

Где практики? Дайте нам объективные доказательства :)

PS. Сейчас почитаю
12207 и RUP

[Green]

Лично мое наблюдение.

RUP, XP, MSF - это методологие, цель которых ответить на вопросы "как", "каким образом", в "какой последовательности".

CMM, CMMI, ISO, IEEE - это стандарты, которые ставят вопросы "что именно", в "каком объеме", в "какой степени". Они не расписывают что и как должно быть сделано (процессы), что бы повысить качество разработки. Они описывают условия, при которых этот уровень повышается.

Пример: если у вас есть баг трекинг, то вы соответствуете 1-му уровню сертификации, если он автоматизирован, то вы уже на 2, а если у вас есть анализ багов, то уже на 3.
При этом что бы реализовать процесс баг трекинга вам нужно выбрать одну из моделей разработки ПО - RUP, XP и т.п. или придумать свой.
B)

Компания, в которой я работал до этого, вынуждена была внедрить у себя вариант RUP, что бы пройти сертификацию на ISO. Впоследствии RUP использовался для получения сертификации на CMMI, но его пришлось слегка модернизировать.

[Mike]

А у Вас процессы имеются?
ИСО 12207 соблюдаете?

Виктор, пожалуйста, можете ещё раз объяснить, что вы подразумеваете под "процессом", а так же "задачей" (task) и work (это вообще не знаю, как перевести).

Что такое ИСО 12207, к сожалению, не знаю (я собственно, управлением качеством не занимаюсь - я тестировщик). Вы не могли бы привести ссылочки и название этого документа?

Мы сертифицированы по ISO 9001:2000 (уточнил).

[Viktor]

Подпроцесс (discipline)
A discipline is a collection of related activities that are related to a major 'area of concern' within the overall project. The grouping of activities into disciplines is mainly an aid to understanding the project from a 'traditional' waterfall perspective - typically, for example, it is more common to perform certain requirements activities in close coordination with analysis and design activities. Separating these activities into separate disciplines makes the activities easier to comprehend but more difficult to schedule.

Поясняю, из ссылки только что выдернул

Process. An ISO 12207 process corresponds roughly to the RUP
concept of a Discipline, but there are more processes in ISO 12207
than there are Disciplines in the RUP.

Качество обеспечивается, когда процессный подход накладывается на деятельностный! (или наоборот?)

[Viktor]

А у Вас процессы имеются?
ИСО 12207 соблюдаете?

Виктор, пожалуйста, можете ещё раз объяснить, что вы подразумеваете под "процессом", а так же "задачей" (task) и work (это вообще не знаю, как перевести).

Что такое ИСО 12207, к сожалению, не знаю (я собственно, управлением качеством не занимаюсь - я тестировщик). Вы не могли бы привести ссылочки и название этого документа?

Мы сертифицированы по ISO 9001:2000 (уточнил).

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

work - работа?

ИСО 12207 - основной стандарт, устанавливает, используя четко определенную терминологию, общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии.

PS. фишку можно аргументировать :)

[barancev]

Качество обеспечивается, когда процессный подход накладывается на деятельностный! (или наоборот?)

Качество обеспечивается, когда его обеспечивают.
А если нет, так хоть так накладывай, хоть этак -- всё равно ничего не получится.

[Mike]

Viktor, мне, честно говоря, казалось что то что вы тут называете процессом, на самом деле есть activity в RUPе. То есть, я всегда себе представлял так, что activity это элементарное действие, которое совершается в рамках одной роли, имеет на входе некий набор артифактов, а на выходе - другой набор. Например, один round тестирования есть деятельность, выполняемая тестировщиком, имеющая на входе partial test plan, а на выходе - баги и логи исполнения тестов. Понятно, что одна activity может включать в себя другие, но в общем случае activity выполняется в рамках одной роли. Так, тест-менеджер на входе в цикл тестирования опять-таки имеет master (system) test plan и test strategy в процессе распределяет выполнение тестов и получает логи исполнения (а так же баги), а на выходе выдаёт отчёт о проведённом тестировании.

[Viktor]

Viktor, мне, честно говоря, казалось что то что вы тут называете процессом, на самом деле есть activity в RUPе. То есть, я всегда себе представлял так, что activity это элементарное действие, которое совершается в рамках одной роли, имеет на входе некий набор артифактов, а на выходе - другой набор. Например, один round тестирования есть деятельность, выполняемая тестировщиком, имеющая на входе partial test plan, а на выходе - баги и логи исполнения тестов. Понятно, что одна activity может включать в себя другие, но в общем случае activity выполняется в рамках одной роли.  Так, тест-менеджер на входе в цикл тестирования опять-таки имеет master (system) test plan и test strategy в процессе распределяет выполнение тестов и получает логи исполнения (а так же баги), а на выходе выдаёт отчёт о проведённом тестировании.

Я и сам до этого разговора так думал, однако это, как мне показал Алексей, не совсем так.
Т.е. подход в RUP другой - не процессный, мне сложно это объяснить, так как у меня нет примеров полноценной разработки по RUP.
Но то что вы говорите про Вашу организацию - этот к чему я стремился у себя, а Алексей показал, что это искажение RUP (здесь под RUP я понимаю не просто методологию разработки, а некий стандарт, правила).
В статье рассказывается как сглаживаются эти грани, но слово грубо (roughly) в определении process мне не нравится. Кстати, еще одна оценка RUP для процессно-ориентированного подхода - слабый (weak)