Принцип как есть программное обеспечение
Невозможность использования программы или как есть
Невозможность использования программы как основание для признания неисполнения правообладателем своих обязательств по договору. Как следствие, предъявление требований о возврате уплаченного и (или) взыскания штрафных санкций. Впрочем, это не единственно возможные претензии.
Наименование суда: Арбитражный суд города Москвы
Номер дела: А40-131571/2012
Дата судебного акта: 19 ноября 2012
Перейдем к делу. Собственно сама фабула.
Истец и ответчик заключили лицензионный договор, по которому были предоставлены неисключительные права (цитируем судебный акт) на использование программного обеспечения (сетевой версии). Права на использования были переданы, что подтверждается соответствующим актом.В последующем, истец как лицо, приобретшее права на использования, обнаружил невозможность использования программного обеспечения в формате сетевой версии. Сетевая версия, по его мнению, означает возможность одновременного использования несколькими сотрудниками в рамках одного проекта программы. Поэтому в рамках исполнения договора должником не передано ни программное обеспечение, ни соответствующие права на него.
Суд отказал в удовлетворении иска.
Основания.
1) Суд посчитал доказанным, что лицензиар (как лицо, приобретшее права на использование ПО) знал функциональные особенности программы. В качестве доказательств выступили: а) деловая переписка; б) информация с сайта лицензиата; в) презентация лицензиатом в офисе лицензиара программы.
3) Невозможность использования программы Истцом выразилось в невозможности одновременной работы разными группами проектировщиков в рамках одного (единого) проекта. Однако желаемый вариант работы программы не является возможным, исходя из той версии программного обеспечения, права на использования которой были приобретены Истцом. Договор не содержит обязанности лицензиата изменять функционал предоставляемой программы.
Наши размышления.
1) Жаль, что истец и ответчик до заключения договора не определили, что хотели приобрести и для чего оно будет использоваться. Не исключаем вариант, когда истец банально и небанальным способом хотел сэкономить, т.к. предположим, что цена версий все же разница.
2) Несмотря на то, что не сторонник включать в договор ненужные условия, согласен, что в данном случае наличие условия о применении принципа «как есть» (скажем так) позволило упростить толкование условий, определение правовых последствий и разрешения ситуации.
3) Также хорошо, что на этапе до заключения истцу предоставляли всю информацию о продуктах. Ну и подобному есть доказательства. Не хотелось бы, эксцессов в арбитражном суде с потребительским мышлением о том, что мы не специалисты в данной сфере. Тем не менее, лучше «подстилать», чтобы не больно было падать)
Принцип «As is» и защита прав покупателя ПО
настоящее время большинство программ в мире продается по принципу «As is» («Как есть»). В результате за проблемы, возникающие в процессе эксплуатации или установки программы, разработчик и распространитель ответственности не несут: они уже сделали все возможное, чтобы таких проблем не возникало. Проще говоря, разработчик программы не отвечает за ее работу. Кажется, что подобное утверждение противоречит здравому смыслу. Однако принцип «As is» это общепринятое положение в мировой компьютерной практике. Давайте рассмотрим юридическую сторону продажи программ.
Прежде всего, надо отметить, что программное обеспечение (далее ПО) защищено законом об авторском праве (в том числе и от несанкционированного копирования). Этот закон предусматривает сохранение за автором (издателем) программного обеспечения нескольких исключительных прав, одно из которых право на производство копий программного обеспечения. Таким образом, приобретение программного продукта пользователем это приобретение лицензии (права) на его использование. Чаще всего это право неэксклюзивное, то есть пользователь не может рассчитывать на единоличное пользование данным программным продуктом.
Итак, лицензия на ПО предоставляет официальное право на использование конкретной программы. Условия лицензии фиксируются в лицензионном соглашении конечного пользователя (End User License Agreement, EULA).
Какие же бывают лицензионные соглашения? Лицензионные права, как правило, различаются для разных категорий продуктов. Персональные операционные системы, настольные приложения, игры, мультимедийные программы обычно лицензируются по следующему принципу: одна лицензия на один компьютер. При этом не имеет значения, сколько физических лиц работает за одним компьютером. Средства разработки чаще всего лицензируются по принципу: одна лицензия для одного физического лица. Серверные продукты обычно предполагают в общем случае две схемы лицензирования: лицензирование на сервер (серверная лицензия для установки на сервер плюс клиентские лицензии для устройств, обращающихся к службам сервера) или лицензирование на процессор (процессорная лицензия для каждого процессора сервера).
Большинство лицензионных соглашений прямо запрещает передачу программного обеспечения во временное пользование или предоставление в аренду.
Многие разработчики ПО используют лицензионное соглашение для ограничения прав потребителя. Разработчик ПО предполагает, что покупатель, приобретая лицензию по принципу «As is», получает программный продукт со всеми имеющимися в нем ошибками и, следовательно, не вправе требовать возмещения ущерба, причиненного его применением. Обычно в подобной лицензии материальная ответственность производителя ограничивается суммой, уплаченной покупателем за программный продукт. Разработчик и распространитель, как правило, не несут ответственности и за утерю пользователем баз данных программы и не производят ее восстановления.
Почему же возможна подобная безответственность? Основной лозунг производителей ПО в настоящее время звучит так: «Невозможно исключить все ошибки из разрабатываемых приложений!» Однако это неверно. Существует множество ПО, функционирующего без ошибок. Более корректно было бы говорить: «Невозможно гарантировать отсутствие ошибок в ПО, поскольку современное ПО очень сложное». Тестирование не позволяет достичь уверенности в отсутствии ошибок, но увеличивает вероятность их выявления.
Утверждение, что гарантий нельзя давать из-за сложности ПО, не выдерживает критики. Современный самолет устройство со сложнейшим программным и аппаратным обеспечением. Его производитель не может быть уверен, что все ошибки были полностью устранены. Тем не менее производитель самолетов, как правило, берет на себя всю ответственность за качество своей продукции. Ни одна другая технологичная индустрия не полагается исключительно на тестирование. Человечеством накоплен значительный опыт, позволяющий утверждать, что тестирование это дорогой и не всегда эффективный способ выявления ошибок, в том числе и в приложениях. Для достижения высокого качества товара необходимо уделить особенно пристальное внимание его производству. Разработаны специальные методы улучшения качества производства, позволяющие производить продукты, не содержащие ошибок. При этом производители берут на себя ответственность за их работу, а также все расходы по возмещению ущерба, к которому привело использование их товара. Ситуация в индустрии программ, однако, противоположна описанной. Очень часто ПО поставляется с заведомыми ошибками, за исправление которых деньги затем берут с пользователя. В целом об индустрии ПО сложилось мнение как о выпускающей ненадежную и некачественную продукцию. Типичный аргумент в защиту: «Ведь никто не делает лучше!» в данном случае неубедителен.
Сегодня во многих системах от работы ПО зависит человеческая жизнь. Как насчет ПО для ядерных реакторов, медицинских инструментов, управления безопасностью автомобиля, производства лекарств? Вы согласны с тем, что его производители не будут нести ответственности за работу своих программ? Смертельное лекарство, авария на атомной электростанции по вине разработчика ПО… Неужели в ближайшем будущем все это произойдет? Нет, это реальность настоящего дня! Известен случай, когда в результате ошибок, допущенных при разработке ПО для медицинского прибора, погибли люди, для лечения которых он применялся. Компьютеры и вычислительные устройства все больше вторгаются в нашу жизнь. Мы всё сильнее зависим от программного обеспечения и полагаемся на его надежную работу. Неужели происшествия, связанные с некачественным ПО, должны стать нормой, чтобы мы задумались? Или уже настало время признать, что качество это неотъемлемая часть ПО? Производители ПО должны нести ответственность за свои продукты. Баги в программах это не неудобства, а дефекты, которые требуется устранить. Давайте представим себе другой мир, в котором на программах, продаваемых по принципу «As is», имеется яркая наклейка «Производитель данной программы не гарантирует ее корректную работу» или «Использование этого ПО может быть вредно для вашего здоровья». А в выпуске новостей, например, передают сообщение о том, что корпорация «Макрософтвер» отзывает 422 млн. копий своего продукта Home XP из-за проблем с печатью документов и гарантирует покупателям возмещение материального ущерба. Не пора ли нам задуматься над тем, как претворить эти мечты в жизнь?
10 важнейших принципов разработки программного обеспечения
Принципы разработки программного обеспечения необходимо знать каждому инженеру, который хочет писать чистый код. Следование этим принципам позволяет вам и другим разработчикам понять проект.
Кроме того, обслуживание или изменение проекта в будущем станет легким. Таким образом, вы в конечном итоге сэкономите деньги, время и ресурсы. Если вы хотите, чтобы проект развивался более плавно, то рекомендуется жить по этим законам.
Мы хотим помочь вам внедрить чистый код. Давайте рассмотрим наиболее распространенные принципы разработки программного обеспечения.
1. Будь проще, Саймон (Keep It Simple Simon, KISS)
При написании следующего большого проекта убедитесь, что ваш код прост и понятен. Код не должен вызывать затруднений у людей при модификации или изменении.
Ваши методы должны быть небольшими, не превышающими 40-50 строк.
Каждый метод должен решать только одну проблему.
У вас в проекте много условий? Убедитесь, что вы разбили их на более мелкие блоки кода.
Always Keep It Simple, Stupid (KISS) позволяет вам и другим программистам быстро выявлять ошибки. Он также помогает вносить дальнейшие изменения в код. Это один из наиболее распространенных принципов бережливого производства в гибкой разработке программного обеспечения.
2. Вам это не понадобится (You Aren’t Gonna Need It, YAGNI)
Большинство программистов с самого начала попадают в ловушку, пытаясь реализовать все функции сразу. В конце концов, часть или большинство из этих функций становятся бесполезными.
Как развивающийся разработчик программного обеспечения, всегда начинайте с добавления всего нескольких методов в класс. Когда ваш проект начнет обретать форму и возникнут новые требования, вы можете добавить больше функций. Таким образом, вы будете придерживаться принципов бережливой разработки программного обеспечения.
Этот принцип экономит время, усилия и расходы, которые тратятся впустую на попытки понять или отладить код.
3. Дважды отмерь и один раз отрежь (Measure Twice and Cut Once)
Некачественно выполненный этап написания требований обычно приводит к более чем 50% проблем в разработке. Поэтому подготовьтесь, разработав системный подход к процессу программирования.
Дважды проверьте все требования проекта, чтобы убедиться, что вы ничего не упускаете и не добавляете лишнего в свой код. После этого сделайте наброски, которые будут направлять весь процесс для получения высококачественного кода. Всегда тестируйте свой проект с самых основ, чтобы убедиться, что все в порядке.
Этот принцип дает гораздо более предсказуемые результаты, особенно если стоимость проекта уже высока. Вы избавите себя от головной боли, связанной с удалением или добавлением строк кода в соответствии с требованиями.
4. Не повторяйся (Don’t Repeat Yourself, DRY)
При написании кода не повторяйтесь. То есть избегайте копирования кода в разные места. В противном случае дальнейшее обслуживание будет трудным. Причина в том, что вам придется изменять код в разных местах.
Эти изменения затронут и тесты, которые нужно будет починить. Для этого потребуется больше времени, усилий и денег.
Чтобы избежать этой ловушки, вы можете извлечь общую логику.
Кроме того автоматизируйте всё, что можно автоматизировать. Тогда ваш код останется бережливым.
Описанные выше шаги помогут повторно использовать код без необходимости копировать его.
5. Бритва Оккама
Следуя принципу бережливой разработки программного обеспечения, всегда начинайте с максимально простого кода. Затем осторожно увеличивайте сложность по мере необходимости.
Простой код позволяет легко представить, разработать, протестировать и исправить продукт на каждом этапе. Он также значительно сокращает количество ошибок, что позволяет программе работать быстрее.
6. Сначала большое проектирование (Big Design Up Front, BDUF)
Этот принцип разработки программного обеспечения утверждает, что разработчик должен сначала завершить проектирование. После этого проект можно реализовать.
Сторонники утверждают, что такой подход помогает обнаруживать проблемы на стадии требований и быстро их решать.
Однако изменения в требованиях к программному обеспечению могут произойти в течение жизненного цикла проекта. Такие изменения могут вызвать трудности или даже сделать дизайн проекта устаревшим.
7. Избегайте преждевременной оптимизации
Мы все согласны с тем, что оптимизация ускоряет процесс разработки и снижает потребление ресурсов. Однако она приведёт к неприятным последствиям, если вы займётесь ей слишком рано.
Причина в том, что приоритизация кода занимает много времени и значительно усложняется, если делать её не вовремя. Кроме того, в процессе реализации наиболее оптимального решения требования могут измениться. Если это произойдет, ваша программа окажется в мусорной корзине или ее будет сложно изменить.
Поэтому начните с самого простого подхода, даже если он не самый оптимальный. Затем в дальнейшем оцените выбранный метод с точки зрения затрат ресурсов и времени. Основываясь на оценке, вы можете выбрать более быстрый алгоритм, который позволит потреблять меньше ресурсов или усилий.
8. Наименьшее удивление
Принцип наименьшего удивления гласит, что желательно разработать функцию, которая не имеет высокого коэффициента удивления.
Компоненты системы должны вести себя так, как того ожидают конечные пользователи. Поэтому результаты вашего проекта будут прибыльными только в том случае, если они очевидны, предсказуемы и последовательны.В противном случае пользователи будут уклоняться от использования функций или структур, которые удивляют или сбивают их с толку.
Вы создаёте программные продукты для людей. Таким образом, вы сильно выиграете от разработки удобных для пользователя функций. Стремитесь соответствовать ментальным моделям, опыту и ожиданиям людей.
Помните, что вы должны привлечь внимание пользователя как можно быстрее. Насколько нам известно, объем внимания современных пользователей резко упал.
9. Закон Деметры
Закон Деметры пытается разделить обязанности между классами и уменьшить связанность между ними.
Настоятельно рекомендуется:
Обеспечить независимость программных объектов друг от друга.
Уменьшить общение или связь между разными классами.
Поместить связанные классы в один и тот же пакет, модуль или каталог для достижения согласованности.
Следование этой идее позволит вашему приложению быть более удобным в обслуживании, понятным и гибким.
10. S.O.L.I.D
Эта аббревиатура обозначает пять принципов объектно-ориентированного программирования и дизайна.
Давайте кратко рассмотрим каждый из этих принципов
Принцип единой ответственности (SRP)
Это принцип разработки программного обеспечения, который гласит, что класс должен иметь только одну причину для изменения. Другими словами, у него должна быть только одна ответственность.
Здесь мы говорим о связанности. Все элементы в структурах или модулях данного класса должны иметь функциональное родство друг с другом. Чётко определив ответственность своего класса, вы повысите его связанность.
Принцип открытости / закрытости (OCP)
Принцип гласит, что вы должны иметь возможность изменять поведение класса, не изменяя сам класс.
Следовательно, вы можете расширить поведение класса за счет композиции, интерфейса и наследования. Однако вы не можете открыть класс для незначительных изменений.
Принцип замещения Лисков (LSP)
В своей исследовательской работе 1988 года Барбара Лисков заявила, что производные классы должны быть спроектированы так, чтобы их при необходимости можно было заменить своими базовыми классами без потери обратной совместимости. Таким образом, вам нужно проявлять осторожность при использовании наследования в проекте.
Хотя наследование выгодно, рекомендуется использовать его в контексте и умеренно. Принцип направлен на предотвращение случаев, когда классы расширяются только за счет общих вещей.
Перед выполнением наследования необходимо учитывать предварительные условия класса.
Принцип разделения интерфейса (ISP)
ISP предпочитает много конкретных интерфейсов одному общему. Цель состоит в том, чтобы иметь гранулярные и специфичные для клиента интерфейсы.
Интерфейсы с множеством поведений сложно поддерживать и развивать. Так что вам следует избегать их.
Принцип инверсии зависимостей (DIP)
Принцип утверждает, что программисты должны полагаться на абстракции, а не на конкретные классы. Мы можем разбить это на две части:
Модули высокого уровня должны быть независимыми от модулей низкого уровня. И те, и другие должны зависеть от абстракций
Абстракции не должны зависеть от деталей реализации. Детали должны зависеть от абстракций.
Итак, в чем причина этого принципа? Ответ состоит в том, что абстракции мало меняются. Следовательно, вы можете легко изменить поведение вашего приватного или публичного кода. Таким образом, вы ускорите его дальнейшую эволюцию.
Заключение
У каждого профессионала должны быть руководящие принципы. Подобные принципы способствуют единству среди профессионалов в обслуживании своих клиентов. Как благородная область деятельности, разработка программного обеспечения не должна оставаться в стороне.
Инженеры-программисты сделают себе одолжение, придерживаясь вышеуказанных принципов разработки и проектирования программного обеспечения. Таким образом вы сможете более эффективно обслуживать своих клиентов и сотрудничать с другими инженерами.
Для вас подготовил перевод Никита Ульшин, Team Lead & JS-разработчик, веду блог ulshin.me и ТГ-канал @ulshinblog.
Комментарии, пожелания и конструктивная критика приветствуются 🙂
Описание бизнес-процессов Как есть (AS IS) и Как должно быть (TO BE)
Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — AS IS и TO BE. И все авторы писали, что сначала необходимо составить нотацию AS IS (буквальный перевод — “как есть”), т.е. как система работает в настоящее время, и только потом приступать к процессу модернизации, т.е. создавать нотацию TO BE (Как должно быть).
Проще говоря, сначала следует изучить, как работает предприятие или отдел сейчас, сделать описание бизнес процесса, и только потом, на основе нотации AS IS, начинать оптимизацию. Но все эти теории хороши, когда есть что описывать по схеме «Как есть». В реальности ситуация чаще всего иная.
Описывать нечего
Если в компании не проводилась ранее оптимизация бизнес-процессов, а это обычная ситуация, нет каких-то четких инструкций, то каждый из сотрудников будет работать по-своему.
Здесь нет ничего необычного. Каждый человек мыслит немного по-своему, у каждого за плечами — собственный опыт. В результате даже самые простые задачи мы все склонны выполнять по-разному.
Например, процесс согласования счета даже в одной организации может выполняться очень по-разному. Кто-то сначала пойдет к начальнику отдела, а кто-то направится сразу в бухгалтерию подписывать счет.
Еще ярче, в тех же продажах, заметна разница между действиями при работе с лидами:
– Один менеджер отправит прайс-лист или коммерческое предложение и успокоится на этом.
– Другой сначала позвонит, все уточнит.
– Третий будет добиваться личной встречи даже там, где без нее можно прекрасно обойтись.
Перед ними стоит задача — обработать лиды и сделать план продаж. Возможно, есть даже перечень рекомендаций, как это лучше делать. Но единой системы нет. И люди начинают нарушать последовательность действий, поступать на свое усмотрение и т. д.
Даже при наличии должностных инструкций в реальности они чаще всего пылятся всеми забытые, а сотрудники работают “кто как привык”. В итоге, мы видим, что системы AS IS, т.е. «как есть», не существует. Нет какой-то единой системы, по которой на самом деле люди работают. И описывать, на самом деле, нечего.
Вы, конечно, можете, попытаться составить модель AS IS на основе инструкций. Но она не будет отражать реальность, ведь их массово нарушают. Можете опросить сотрудников, но любая из моделей будет отражать работу только части людей либо что-то «усредненное», что вообще не будет иметь отношения к реальности, т.к. все работают похоже, но — не так.
Описывать незачем
Еще один важный аспект, с которым я столкнулся на практике. О том, что в компании что-то делают неправильно, все и так давно догадываются. Иначе бы вас, как специалиста, не пригласили. И от вас не ждут описания существующих проблем, они часто и так понятны. От вас ждут решения — как надо работать.
Чаще всего клиенты ожидают, что бизнес-консультант придет, осмотрится, опросит людей, после чего выдаст рекомендации, как надо делать, чтобы решить существующие проблемы. Т.е. людям не нужны нотации «Как есть». Им сразу хочется увидеть «Как должно быть».
Зачем создают нотации AS IS?
Создавать нотации AS IS для себя вы можете, это даже может быть удобно и полезно. В конце концов, графика помогает упорядочить мысли, разобраться точнее лично для себя, что и как происходит. Но в рекомендованной последовательности действий указывается обязательный этап предоставления этой нотации клиенту.
Бизнес-консультанту такой подход выгоден с финансовой точки зрения. Большой объем работы повышает ее стоимость. Но нужно ли это заказчику? Он и сам знает, что компания как-то работает, потому что бизнес приносит прибыль и т. д. Вас он нанимает не для того, чтобы за их деньги вы им поясняли, какую схему работы они сами организовали. Им хочется увидеть от эксперта результат, т.е. схему, которая будет работать лучше.
Возникает резонный вопрос. А как без описания того, что есть, вы сможете выдать рекомендации, что нужно изменить? Но ведь вы — специалист, эксперт в своей сфере деятельности, вас потому и позвали, что верят, вы разберетесь и сумеете выдать правильный результат.
Конечно, вы будете вести свои записи. Вполне возможно, что вы даже оформите их в виде нотации, как это и описывают в учебниках. Вы можете использовать эти записи для уточнения каких-то моментов в работе компании. Но этот этап нужен вам, а не заказчику.
Потому не имеет смысла тратить силы и время на составление полноценной нотации AS IS с сопроводительной документацией, включать этот этап в план работ и т. д. Если ваш клиент не ждет от вас этого этапа в обязательном порядке, что иногда случается в крупном бизнесе или в случаях, когда заказчики тоже читали те самые учебники, предоставляйте сразу решение — TO BE. Вы должны быть на стороне клиента, и давать ему то, что реально нужно. Это подход продуктивности.
Пример использования нотации AS IS и TO BE
Я сотрудничал с хлебокомбинатом, который имеет цех выпечки, склад и подразделение охраны. При составлении нотации AS IS стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.
Как выглядит процесс:
На самом деле, этапы, связанные с действия охраны, не имеют особого смысла, так как охранники не проходили никакие специализированные курсы, в хлебе они вообще не разбираются. Потому и проверить охрана не может ничего, кроме количества. Но количество проверяется еще раз позже при приеме на склад.
Очевидно, что для оптимизации нужно убрать участие охраны в процессе, а контроль выполнять другими методами. Охрана при этом работать на предприятии будет, выполнять контроль периметра, входной контроль и т.д. Но в этом процессе она не нужна.
Процесс TO BE будет таким: