Давно замечаю, что многие, кто использует UML и вот такие "методики" как ОО анализ, совершенно не владеют синтаксисом и семантикой такого языка.
Как может бизнес-потребность зависеть от подхода бизнес-анализа. Если используешь собственную нотацию, то следует потрудиться над представлением легенды.
Спасибо за быстрый ответ, честно признаюсь, не ожидал вообще, что ответите. Еще раз спасибо.
У меня опыта работы с инструментами для управления тестами кроме test-link нет. Правда сама среда тестирования использовала Testcomplete. Потому интересно было узнать о чем-то более передовом. К сожалению описываемые Вами продукты, вряд ли доступны нам по цене, хотя я у них на сайте не нашел этой информации бегло.
Мне как-то сложно представить набор таких атомарных тестов, которые могут комбинироваться в произвольные цепочки исполнения. Хотя, возможно, вы имели в виду, устойчивые тестовые процедуры, оформленные так, чтобы быть независимыми от данных (данные задаются снаружи), а сама тестовая процедура воспроизводит какой-то шаг, задачу, работу бизнес-процесса с привязкой к реализации:
— войти пользователем
— выполнить настройки
— сделать А
— сделать Б
— и т.д.?
Странно, что к такой интересной статье нет ни одного комментария.
У меня ряд вопросов?
1. что за инструмент управления тестами Вы используете?
2. как следует разрабатывать тесты, чтобы удовлетворять описываемым потребностям?
Мне кажется, там простым (на английском, что редкость) языком и очень лаконично, но емко разобраны как вообще разрабатывать use case. Конечно, книга издана давно. Предисловие написано Иваром Якобсоном. В аннотации можно найти следующее.
In Use Case Modeling, experienced use case practitioners Kurt Bittner and Ian Spence share their tips and tricks for applying use cases in various environments. They delve into all aspects of use case modeling and management, demonstrating how development teams can capitalize on the approach's simplicity when modeling complex systems.
In this ready reference, readers will discover how to:
Introduce a development team to use cases and implement a use case approach
Identify the key elements of a use case model, including actors; and the components of a use case, including basic flow, preconditions, post-conditions, sub-flows, and alternate flows
Master the objectives and challenges of creating detailed descriptions of use cases
Improve their descriptions' readability and consistency
Prevent and remedy common problems arising from the misuse of include, extend, and generalization use case relationships.
Organize and conduct a review of a use case model to realize the best possible approach
Книгу могу дать, хотя Вы ее легко найдете в открытом доступе.
Я не являясь математиком в смысле эксперта, запросил консультацию у математика, изучающего и преподающего матлогику в течение нескольких десятков лет. Получил аналогичный ответ сходу. Т.е. это у человека сработал математический инстинкт.
Это не статистика. Это ваше субъективное наблюдение, возведенное в ранг обобщения. Так вам угодно строить диалог с читателями, манипулируя и провоцируя их внимание к вашим идеям.
Вы никак не можете уяснить и запомнить, что иметь в виду пишется вот так, а не иначе. Какой-то психологический залом у вас?
Понятно, что мир большой, и я не слышал ни одного аналитика, который бы говорил подобным образом. Это, конечно, не приводит к тому, что нет аналитиков так говорящих. Заметьте, я не делаю общих выводов из своего ограниченного наблюдения, а вы почему-то делаете. Не придерживаетесь ни формальной, ни о более строгой математической логике.
я набрел на две ключевые идеи, которые мне не дают покоя, потому что переворачивают все классические представления о том как происходит принятие решений
А почему дальше идут три пункта. И в чем их особость? В том, что мышление субъект группы? И только группы? Мне кажется, это слишком смелое утверждение. Или ты предполагаешь, что индивидуум, даже если он один, все равно ведет себя как группа, общаясь, так сказать, с внутренним собеседником?
Да, я сразу хотел пометить статья как перевод. И в комментариях там писал модератору, если он не затерся. А можно ли прямо сейчас пометить как перевод?
Чем инклюд отличается от экстенда на рисунке? Если по UML там логика простая базовый ВИ, тот от которого идет стрелка в случае инклюд, включает некое поведение в обязательном порядке, а в случае экстенда стрелка идет в сторону базового ВИ, т.е. его расширяет при соблюдении какого-то условия.
Тут же получается, что фотографирование лица включает заполнения профиля. Не ясна логика чтения схемы.
Обзоры устаревают. Раньше делал, что-то. Одно время использовал https://www.3ds.com/products-services/catia/products/no-magic/magicdraw/. Есть даже академическая лицензия.
Был знаком даже с основателем вот этого проекта: https://www.modeliosoft.com/en
Давно замечаю, что многие, кто использует UML и вот такие "методики" как ОО анализ, совершенно не владеют синтаксисом и семантикой такого языка.
Как может бизнес-потребность зависеть от подхода бизнес-анализа. Если используешь собственную нотацию, то следует потрудиться над представлением легенды.
У меня опыта работы с инструментами для управления тестами кроме test-link нет. Правда сама среда тестирования использовала Testcomplete. Потому интересно было узнать о чем-то более передовом. К сожалению описываемые Вами продукты, вряд ли доступны нам по цене, хотя я у них на сайте не нашел этой информации бегло.
Мне как-то сложно представить набор таких атомарных тестов, которые могут комбинироваться в произвольные цепочки исполнения. Хотя, возможно, вы имели в виду, устойчивые тестовые процедуры, оформленные так, чтобы быть независимыми от данных (данные задаются снаружи), а сама тестовая процедура воспроизводит какой-то шаг, задачу, работу бизнес-процесса с привязкой к реализации:
— войти пользователем
— выполнить настройки
— сделать А
— сделать Б
— и т.д.?
У меня ряд вопросов?
1. что за инструмент управления тестами Вы используете?
2. как следует разрабатывать тесты, чтобы удовлетворять описываемым потребностям?
In Use Case Modeling, experienced use case practitioners Kurt Bittner and Ian Spence share their tips and tricks for applying use cases in various environments. They delve into all aspects of use case modeling and management, demonstrating how development teams can capitalize on the approach's simplicity when modeling complex systems.
In this ready reference, readers will discover how to:
Introduce a development team to use cases and implement a use case approach
Identify the key elements of a use case model, including actors; and the components of a use case, including basic flow, preconditions, post-conditions, sub-flows, and alternate flows
Master the objectives and challenges of creating detailed descriptions of use cases
Improve their descriptions' readability and consistency
Prevent and remedy common problems arising from the misuse of include, extend, and generalization use case relationships.
Organize and conduct a review of a use case model to realize the best possible approach
Книгу могу дать, хотя Вы ее легко найдете в открытом доступе.
Понятно, что мир большой, и я не слышал ни одного аналитика, который бы говорил подобным образом. Это, конечно, не приводит к тому, что нет аналитиков так говорящих. Заметьте, я не делаю общих выводов из своего ограниченного наблюдения, а вы почему-то делаете. Не придерживаетесь ни формальной, ни о более строгой математической логике.
А почему дальше идут три пункта. И в чем их особость? В том, что мышление субъект группы? И только группы? Мне кажется, это слишком смелое утверждение. Или ты предполагаешь, что индивидуум, даже если он один, все равно ведет себя как группа, общаясь, так сказать, с внутренним собеседником?
Вопрос не простой, но к.м.к таким человеком (или группой людей) может быть архитектор решения.
Как минимум, когда решение достаточно типовое, ну и не прибавляет стоимости и не будет увеличивать сроки поставки.
Тут же получается, что фотографирование лица включает заполнения профиля. Не ясна логика чтения схемы.