Данная статья затрагивает некоторые аспекты при выборе подхода к проектированию предметной области для сложных корпоративных систем. В ней исследуются причины возникновения классических подходов и их анализ, для возможного улучшения. Это моя первая статья на данную тему.
Рубрика «use case»
Мой путь к быстрой и понятной архитектуре, или зачем я выбросил агрегаты из DDD?
2025-01-26 в 13:15, admin, рубрики: .net, aggregate, C#, DDD, domain model, domain-driven design, Entity, repository, services, use caseUML для разработчиков
2020-03-05 в 8:42, admin, рубрики: activity diagram, archimate, class diagram, enterprise architect, oauth2, sequence diagram, UML, UML Design, use case, Блог компании Программный Продукт, диаграммы, Проектирование и рефакторинг, управление проектамиИнтернет полон статей про UML, вы найдете сотни примеров для каждого вида диаграмм, и без проблем создадите свои, нотация не сложная. Но так ли уж необходимо тратить на это время? Наш богатый опыт говорит «Да». Если у вас в команде более 2 человек и проект от 3 месяцев, то уже имеет смысл отрисовать 2-3 вида диаграмм. В одной нашей команде более 30 человек, проект длительностью более 3 лет, и мы используем...2-3 вида диаграмм.
Нотация UML избыточна. С другой стороны она недостаточна для проектирования распределенных систем, и здесь нам помогает Archimate. В этой статье мы расскажем, что действительно полезно из всего этого многообразия, и рассмотрим на примере полный цикл создания диаграмм для проекта.
Читать полностью »
Тестирование методом черного ящика
2019-08-07 в 11:10, admin, рубрики: blackbox, boundary value, Copeland, decision table, equivalence class, pairwise, state-transition, testing, use case, Анализ и проектирование систем, Тестирование IT-систем, тестирование поКнига "A Practitioner's Guide to Software Test Design" Lee Copeland была опубликована в 2003 году.
С тех пор она надежно закрепилась в списке книг, которые обязательно должен прочитать любой тестировщик. Её стоит прочитать в оригинале. Читается очень приятно: язык не сложный, стиль легкий. По ходу книги автор слегка иронизирует над собой, своими учениками, читателями и в целом над сферой нашей деятельности.
Далее приводится не перевод, а скорее подробный конспект раздела “Техники тестирования методом черного ящика”, в котором содержится описание применения техник тест-дизайна.
Правильный выбор СрЗИ: от рекламных листовок к use case
2017-09-13 в 17:46, admin, рубрики: Cisco, use case, Блог компании Cisco, выбор, информационная безопасность, проектирование систем, сетевая безопасность, сетевая инфраструктураРаздается недавно звонок:
— Добрый день! Я бы хотел получить спецификацию на межсетевой экран Cisco ASA. У меня уже есть спецификации от компании <имярек> и я хочу сравнить их и выбрать подходящую. Вы можете мне помочь в этом?
— Да, конечно. А для чего вам нужна Cisco ASA?
— Мне необходимо заблокировать Tor.
— А вам нужна именно Cisco ASA для этого?
— Ну а как? Вот компания <имярек> говорит, что ее межсетевой экран блокирует Tor. Поэтому я хочу сравнить стоимость их экрана с вашим.
— То есть вам нужно заблокировать Tor и вы ищите для этого нужное вам решение?
— Да-да (раздраженно). Так вы можете мне составить спецификацию? Какие исходные данные вам нужны?
— Для решения именно этой вашей задачи, если другие перед вами не стоят, необязательно использовать Cisco ASA. Блокировать работу с Tor вы можете с помощью различных наших решений — Cisco Web Security Applaince, Cisco Umbrella Security Internet Gateway, Cisco Cloud Web Security, Cisco Meraki MX, Cisco Firepower, Cisco AMP for Endpoints… В конце концов вы можете с помощью скрипта подгружать адреса узлов сети Tor в маршрутизатор Cisco ISR и блокировать их с помощью ACL. В последнем случае вам и тратить ничего не придется.
— Да? Вот блин. Мне надо тогда подумать…
— Давайте мы с вами вместе составим перечень задач, которые вам надо решить, и угроз, с которыми надо бороться, и тогда уже выберем наилучшим образом подходящий продукт?
— Хорошо, давайте. Вы сможете к нам подъехать завтра к 10-ти утра?
— Конечно.
Читать полностью »
Как использовать сценарии использования для точной оценки трудоемкости работы
2015-09-24 в 11:58, admin, рубрики: use case, варианты использования, оценка, сценарии использования, трудоемкость, управление проектами, метки: трудоемкостьКаждый из программистов и руководителей разработки хоть раз, но попадал на сроки, т.е. нарушал их, сильно или не очень.
Попробуйте открутить назад все Ваши проекты и оцените реальное опоздание по ним.
Может оказаться, что задержки достигают просто гигантских значений.
Автор статьи видел проекты с задержкой сроков в 400% и 700%!
Бытует мнение, что разрабатывать программы без опоздания невозможно в принципе.
Вообще, причина такой точки зрения ясна, ведь люди не провидцы и не могут видеть будущее.
На момент оценки трудоемкости ТЗ есть не всегда. И даже если оно есть, фактор неизвестности всё равно продолжает играть огромную роль – ведь люди, к сожалению, действительно не провидцы, и каким бы подробным не было ТЗ, всё равно остаются моменты, скрытые от глаз.
Кроме скрытой функциональности, на ошибочную оценку также довольно сильно влияет квалификация и личный опыт программирования самого оценщика (человеку без личного опыта программирования труднее оценить сколько времени займёт разработка).
Интересно, что сценарии (варианты) использования позволяют довольно точно оценить трудоемкость работ.
Практика показала, что можно достигнуть 20% точности (=%ошибки) при оценке. А ведь опоздание 20% это совсем не 700%, верно?
Как это сделать? Читать полностью »