Посылки были иначально ложными.
80% требований исходят из предметной области, они практически не меняются. И только 20% связаны с персонализацией под заказчика.
Но для этого нужно знать предметные области на системном уровне.
Меняются не требования, а представления исполнителей о предметной области, процесс изучения которой прячется под бесконечный цикл разработки.
Спасибо за теплые отзывы.
В декабре 2014 вышла моя новая книга «СУБД для программиста. Базы данных изнутри».
Возможно будет полезной кому-то из прежних читателей.
Аннотация, информация и ссылки: arbinada.com/main/node/1372
В случае развертывания SQL Server Express — может использовать. В случае PDFCreator — тоже. Зафиксировать их версии возможным не представляется. Поэтому предлагаемый подход в таких случаях не работает.
Если вы не несете ответственность перед клиентом, скажем, за ошибку в SQL Server Compact (который поставляется вместе с вашей системой простым copy deployment), это означает, что вы можете клиенту предложить обратиться в Микрософт, а не к вам.
Поскольку это не так практически всегда, предлагаю не заниматься терминологическими изысками.
Совершенно верно, это называется поглощение бинарников. Развертывая их в составе своей системы, вы несете ответственность за них перед клиентами, не имея исходного кода, полагаясь исключительно на тесты типа «черный ящик».
В некоторых случаях это возможно, когда компонент достиг определенного уровня зрелости и риск обнаружения в нем критичных ошибок невелик. Иначе это не работает., к сожалению.
Давайте вернемся к примеру. У вас есть система, развернутая на сотнях рабочих мест. Предположим, она использует упомянутый PDFCreator для печати. Разработчики PDFCreator выпустили новую версию. Несколько клиентов обновили PDFCreator и обнаружили, что печать больше не работает (технические причины описаны в тексте). Они начинают звонить в поддержку вендора.
Вы предлагаете:
— выбрать другой компонент (надо полагать, его разработчики более ответственны, такое тоже бывает). Извините, этот вариант нам не подходит.
— какой-то другой вариант кроме (1) поглощения или (2) поддержки совместимости со всеми версиями (механизм также описан в тексте)
Готов внимательно выслушать про другой вариант, только не теоретический, а подкрепленный реальной практикой в похожих условиях.
Компонент программной системы — это минимальная единица развертывания. В данном случае речь идет еще и компоненте в понятии COM.
В продуктовом софтостроении каждый сторонний компонент, то есть поставляемый третьей стороной, увеличивает риски несовместимости и отказа отдельных функций основной системы.
Жестко зафиксировать конфигурацию установленного ПО у сотен клиентов не представляется возможным. Поэтому для относительно небольших компонентов выбирается вариант его внедрения в общую систему. В этом случае наличие исходников значительно облегчает задачу внедрения и последующего сопровождения.
Простой пример был приведен — экспорт в PDF. Поскольку разработчики PDF Creator безответственно относятся к разработке, то эта функция должна быть внедрена в основную систему, возможно уже на базе другой реализации.
Другие часто встречающиеся примеры — архивация и распаковка, сканирование (без драйверов), доступ к БД, генерация отчетности, реализации сетевых протоколов разных уровней и т.д.
Чем больше основная система, тем больше в ней внедрено сторонних решений, зависимость с которыми разорвана на уровне поглощения исходников.
К сожалению, это лишь аналог пожеланий того, что поставщик компонента должен обеспечить функционирование нескольких версий одновременно на одном устройстве.
В случае COM-DLL сделать это даже проще, чем для сборки в GAC: всего лишь установить DLL новой версии в другой директорий, и не надо никаких strong name и прочего.
В тексте упомянуты, как минимум, 2 тезиса по частным решения на относительно малом масштабе:
— ответственно относиться к разработке сторонних компонентов
— снизить риски наличием исходного кода
В общем случае проблема не решается. Подтверждается великим множеством эксплуатируемого ПО, которого поставщики уже не поддерживают. Далеко не всегда у такого ПО есть исходники, что вынуждает клиентов иметь в резерве уже давно не производящееся «железо». Далеко не всегда даже имеющиеся исходники могут быть перенесены в новую архитектуру.
80% требований исходят из предметной области, они практически не меняются. И только 20% связаны с персонализацией под заказчика.
Но для этого нужно знать предметные области на системном уровне.
Меняются не требования, а представления исполнителей о предметной области, процесс изучения которой прячется под бесконечный цикл разработки.
В декабре 2014 вышла моя новая книга «СУБД для программиста. Базы данных изнутри».
Возможно будет полезной кому-то из прежних читателей.
Аннотация, информация и ссылки: arbinada.com/main/node/1372
Поскольку это не так практически всегда, предлагаю не заниматься терминологическими изысками.
С сутью же ваших предложений понятно, спасибо.
В некоторых случаях это возможно, когда компонент достиг определенного уровня зрелости и риск обнаружения в нем критичных ошибок невелик. Иначе это не работает., к сожалению.
Спасибо, как вариант иногда проходит. Например, в случае embedded СУБД, они развертываются примерно так.
Вы предлагаете:
— выбрать другой компонент (надо полагать, его разработчики более ответственны, такое тоже бывает). Извините, этот вариант нам не подходит.
— какой-то другой вариант кроме (1) поглощения или (2) поддержки совместимости со всеми версиями (механизм также описан в тексте)
Готов внимательно выслушать про другой вариант, только не теоретический, а подкрепленный реальной практикой в похожих условиях.
В продуктовом софтостроении каждый сторонний компонент, то есть поставляемый третьей стороной, увеличивает риски несовместимости и отказа отдельных функций основной системы.
Жестко зафиксировать конфигурацию установленного ПО у сотен клиентов не представляется возможным. Поэтому для относительно небольших компонентов выбирается вариант его внедрения в общую систему. В этом случае наличие исходников значительно облегчает задачу внедрения и последующего сопровождения.
Простой пример был приведен — экспорт в PDF. Поскольку разработчики PDF Creator безответственно относятся к разработке, то эта функция должна быть внедрена в основную систему, возможно уже на базе другой реализации.
Другие часто встречающиеся примеры — архивация и распаковка, сканирование (без драйверов), доступ к БД, генерация отчетности, реализации сетевых протоколов разных уровней и т.д.
Чем больше основная система, тем больше в ней внедрено сторонних решений, зависимость с которыми разорвана на уровне поглощения исходников.
В случае COM-DLL сделать это даже проще, чем для сборки в GAC: всего лишь установить DLL новой версии в другой директорий, и не надо никаких strong name и прочего.
Однако… см. по тексту.
— ответственно относиться к разработке сторонних компонентов
— снизить риски наличием исходного кода
В общем случае проблема не решается. Подтверждается великим множеством эксплуатируемого ПО, которого поставщики уже не поддерживают. Далеко не всегда у такого ПО есть исходники, что вынуждает клиентов иметь в резерве уже давно не производящееся «железо». Далеко не всегда даже имеющиеся исходники могут быть перенесены в новую архитектуру.
Попробовал сделать примерное сравнение с курсами по специальности 22-01 «Вычислительные системы, комплексы и сети», совпадение процентов на 80.
Обучение студентов: американские университеты в сравнении с советским вузом