В теме 8 ответов, и 5 участников, последнее обновление сделано пользователем 
Андрей Курьян 13 г, 3 мес. назад.
-
Сообщения
-
Как вы формулируете требования к расширяемости системы (extensibility), чтобы они были проверяемыми при этом?
Приветствуются любые примеры.Надеюсь как программист смогу быть полезен.
Есть два основных критерия:
1) Пометка OpenSource — если прилага OpenSource она расширяема, а степень расширяемости зависит от уровня "гавнакода" (сори за проф термины), и ровнорукости программеров которые будут расширять.
2) Если прилага не OpenSource — ищем документацию по API. Если она есть — прилага расширяемая. Степень расширяемости зависит от толщины этой самой документации.И третий критерий (дополнительный):
3) Если у софтины большое комюнити в котором есть библиотека расширений, то если соотнести популярность приложения и объем библиотеки — тоже можно судить о расширяемости )Простите формул не дам.
Спасибо, Phyro! Про API мысль одна из первых пришла мне в голову, а вот про OpenSource не подумала.
Еще, на мой взгляд, в качестве "гаранта" расширяемости может выступать использование архитектурных шаблонов, позволяющих разделять данные, логику и представление (MVC, MVVM и иже с ними). Проверить можно, скорее всего, через код ревью. Либо попробовав заметить любой из слоев другим аналогичным и оценив, сколько затрат на это ушло.Не факт что факт применения паттернов может помочь. Если система совсем закрытая, то вы просто не "подцепитесь" туда. (По крайней мере не без гемора). Тогда должна быть либо дока как подцепиться, либо хотя бы все это должно управляться человеко читаемым конфигом (незакомпилированном) и быть сделано на каком-нибудь стандартном фрэймворке (хотя в случае java и .net так и будет с вероятностью 99,9% — извращенцев и неучей в мире программеров ой как много — имеется ввиду про стандартный фрэймворк но не разу про незакомпилированный конфиг). Ну или у вас под рукой должен быть спец по дизасемблеру того исполняемого кода, который вы получили.Если можно проверить через код ревью ) То вам паттерны не так критичны. Хотя опен сорс сделанный с применением паттернов — это классно.
OpenSource + Patterns = Ultra-Mega Extensibility
p.s. mvvm — мне кажется не в ту степь. это паттерн сугубо для n-tier приложений где это самое n-tier реально надо. (типа вьюшку от модели полностью изолировать). а тут реально надо обработчики добавлять.
ох, чувствую ща тухлыми яйцами закидают
Тема для меня новая, так что расскажу, как я рассуждала. Я рассматривала расширяемость в нескольких аспектах:1) Возможность дорабатывать систему "изнутри" (отсюда требования к разбиению на слои, а также к поддержке модульности): закладывание такой архитектуры, которая позволит в дальнейшем "наворачивать" функционал без особого труда и последствий для быстродействия и устойчивости системы.
2) Возможность дорабатывать систему "снаружи" сторонними разработчиками. Сюда я отношу предоставление API и идеологию Open Source.Теоретически можно, наверное, выделить еще и расширяемость, связанную с аппаратной составляющей (но тут важно не перепутать с масштабируемостью, потому что она тоже где-то рядом). К примеру, закладывание возможности в один прекрасный день перевести систему на cloud-ы — не оно ли?
P.S. Насколько я знаю, MVVM представляет собой адаптацию MVC для WPF/Silverlight. Упомянула, т.к. разок использовала на практике и получила большое удовольствие от легкости смены вьюхи )
Вставлю и я своих 5 копеек (:Мне приходилось довольно мало участвовать в формулировке и документировании таких требований. В реальности просьбы/требования заказчика типа "необходимо, чтобы можно было легко добавлять в систему новые модули" почти никогда не попадали в SRS (ТЗ), а даже если и попадали, то я не припомню, чтобы они хоть раз становились конкретными, измеримыми или проверяемыми (в общем, не SMART ни разу). Т.е. вот так вот “The average [effort|cost] to extend X to [meet requirement Y] shall not exceed Z.” в моей практике эти требования точно не выглядели (:
Чаще всего это требование доходило до архитектора в устной форме (или в таком в общем виде уже упомянутом выше), и уже он, создавая архитектуру, пытался его учесть. Варианты были, да, уже упомянутые:
- разработка API (да, само собой, сперва определялся список функций, которые должны быть доступны через API)
- модульная архитектура
- n-tier в том или ином виде
Хотя, я вот пока писал, припомнил, что клиенты иногда делали такие требования более конкретными, упоминая не просто слова "новые модули", а что-нибудь типа:
- необходимо, чтобы в будущем можно было интегрировать нашу систему с соц сетями
- необходимо, чтобы систему не пришлось переписывать, чтобы добавить поддержку IE 9
- необходимо, чтобы в систему в будущем можно было легко добавить также поддержку форматов A, B, CКстати, вот полезные ссылки по теме:
http://www.opfro.org/index.html?Compone … l~Contents
http://en.wikipedia.org/wiki/Extensibility
http://en.wikipedia.org/wiki/Extensibility_pattern
http://en.wikipedia.org/wiki/Extensible_programmingКак Юра правильно отметил, описать требования к расширяемости/модифицируемости можно, а вот с проверкой их всё очень печально в большинстве случаев.Позволю себе кинуть пучок мыслей (майндмапу) с одного семинара, может кому-нибудь пригодится.
На самом деле… Есть такие параметры как зацепление (cohaision), связанность (coupling) и абстракция. Эти параметры еще и численно измеримы. И есть что-то типа закона максимальной гибкости. Это когда модуль приложения на столько же несвязан на сколько и абстрактен относительно других модулей. И короче если строить прямую (0;1 — 1;0). Координаты точек по каждому модулю (по этим двум параметрам) должны быть около этой прямой. Тогда у приложения будет высокая степень модифицируюемости. А зацепление по хорошему надо максимизировать если хочешь отдельный модуль сделать гибким (но не всегда это оправдано на мой взгляд). (Все вместе это и определит расширяемость)
но что-то мне подсказывает (и подсказывает на практике). помимо расширяемости надо иногда еще и учитывать на сколько расширения будут конфликтовать друг с другом в рамках предложенной архитектуры. а это совсем другая печальная история
P.S> про MVVM — да все почти так. Я тупанул. просто это скорее не просто чтобы подменять одну вьюшку (ее можно и тупо с mvc подменить если приложение правильно организовано). Это скорее чтобы подменить весь слой view (если так можно выразиться). Например подменить web-морду на какой-нибудь клиент. Правда я видел извращенный способ подмены веб-морды. Люди писали xhtml упращенный интерфейс и парсили его как xml своим клиентом. Очень оригинально на мой взгляд, и если приложение не гибкое и все из себя закрытое, но веб. Это может быть прикольным решением. эдакое bot-api.
Как вы формулируете требования к расширяемости системы (extensibility), чтобы они были проверяемыми при этом?
Приветствуются любые примеры.ИМХО, следует разделить требования к расширяемости на 2 категории:
1) Требования, которые определяют интеграцию разрабатываемой системы с другими уже существующими системами (или видами систем). Эти требования могут быть достаточно четко определены и, соответственно, поддаются тестированию и проверке. Решениями являются, например, API.
2) Требования, которые относятся к будущему развитию системы, в том числе, расширению ее функций. Примером таких требований являются заявления заказчика типа: "в будущем мы хотим расширить систему так-то и так-то. Нужно предусмотреть такую возможность". Методы работы с этими требованиями, в т.ч., методы проверки, должны быть другими. Решения по этим требованиям тоже обладают определенной спецификой.На самом деле, 2 вид требований — интересная тема.
Вы должны авторизироваться для ответа в этой теме.
