коллеги, давайте, наконец, напишем что-нибудь. )

[Dimka]

Игорь хочет карточки. Я считаю, что таблетка удобнее, т.к. ее можно повесить на связку ключей и если электричества нет, то откроешь ключом, когда как карточка отдельно от ключей и их можно просто забыть.

А "и того, и другого - и можно без хлеба"?


Что я ещё хочу сказать о жизни. Одиночный разработчик все детали может, если ему хочется, держать в голове. Но даже ему лучше записывать - чтобы не забылось. В группе это уже совсем невозможно, поскольку у каждого свои мозги. Каждый субъективно выбирает из множества требований те, которые считает наиболее важными - он про них хорошо помнит и ради их сохранности готов подзабыть или ненароком поменять менее важные требования. Беда в том, что у каждого в группе свои предпочтения, поэтому неминуемо в головах общая картина начинает размываться и рассогласовываться. Бумажка - это связующее звено. Периодически её надо коллективно перечитывать и обсуждать, чтобы восстановить единство картины проекта у всех членов группы. Вместо бумажки в группе может быть идеолог - его задача ходить и "разговоры разговаривать" со всеми, пропуская через себя все мнения и передавая всем эти мнения; или для особо маленькой группы - регулярные разговоры в общем кругу. Ещё один вариант - ведущий, тогда проект он разрабатывает как бы единолично, а остальные от него получают конкретные задания; хотя ведущий с остальными может что-то обсуждать, вся ответственность за целостность лежит на нём, поэтому он может позволить себе какие-то детали держать в своей голове и не парится по поводу того, все ли эти детали знают. Без ведущего - обязанность каждого следить за собой и всеми остальными, чтобы не возникало разных пониманий.

Поэтому фиксация всяких мелочей и подробностей для группы жизненно необходима - она обеспечивает единство представления о проекте. На это стоит тратить усилия, это очень важно для группы/команды, занятой совместной работой на общую цель, но с разделением труда и ролей.

[RXL]

Да-да. Хочешь - карточку, хочешь - таблетку, хочешь - все сразу, а можно и без всего.

Добавлено через 6 минут и 27 секунд:
Так с чего же начнем? Уточняем спецификацию и расписываем алгоритмы поведения устройства?

Добавлено через 6 минут и 45 секунд:
У нас уже есть трекер: http://redmine.shelek.su/projects/vu-lock-controller
Проект открытый - читать можно без регистрации. Желающие принять участия - прошу зарегистрироваться и сообщить свои логины в ЛС для прикрепления к проекту и роль на трекере (менеджер, разработчик). При логине пишите там осмысленные ФИО - мусор я периодически баню, т.к. иначе его не определишь.

SVN так же открыт для чтения. Для записи мне нужен произвольный логин/пароль в ЛС.

Так получилось, что я вроде как выполняю роль ведущего. Мне это не очень нравится, т.к. хотелось бы в процессе освоить новые для себя технологии и инструменты и нужен если не ведущий (если ни у кого не возникнет такого желания), то хотя бы совместный ведущий.

[Ochkarik]

все бы вам резать!)
тут имхо не резать надо, а аккуратно скопипастить по подразделам (к примеру):
1. ТЗ
2. Обзор существующих изделий
3. Разработка функциональной схемы и сценариев работы в различных режимах(с точки зрения пользователя)
4. Разработка алгоритмов работы отдельных модулей
5. Разработка протоколов обмена между отдельными модулями (что, когда и кто куда передает - информационная составляющая)
6. Выбор и обоснование аппаратной реализации
7. Программная реализация
8. Тестирование отдельных модулей
9. Тестирование устройства в целом

я это как-то так вижу... поправьте если ошибаюсь.

[Dale]

Поскольку проект некоммерческий, он вполне может обойтись без ТЗ. Настоящее ТЗ изобилует бюрократией и бухгалтерией чуть менее чем полностью.

Что сейчас действительно необходимо, так это сбор и обработка бизнес-требований. Из них будет следовать все остальное.

[Ochkarik]

Dale, ну я не ГОСТовское ТЗ имел в виду) именно - бизнес)
в остальном - есть недочеты?

[Dale]

В принципе все пункты правильные, только IMHO некоторые находятся не на своих местах. Например, обзор существующих решений делается после ТЗ, а хорошо бы с него начать. В п.3 функциональная схема соседствует со сценариями, а по логике должна разрабатываться для их реализации, т.е. после, ну и прочие причинно-следственные связи не везде соблюдены.

Я обычно строю проекты в таком порядке:

1. Сбор бизнес-требований.
2. Их обработка и выпуск документа Vision (см. ReadySET).
3. Сбор пользовательских требований.
4. Выпуск спецификации требований, в т.ч. функциональных, на основе модели прецедентов (Use Case).
5. Разработка приемочных тестов на основе п.4.

Ну и так далее, по давно накатанной колее с использованием V-модели (у меня к ней давняя симпатия).

[Dimka]

Например, обзор существующих решений делается после ТЗ, а хорошо бы с него начать.

Так всё может закончиться выбором одного из существующих решений Насколько я понял, x77 хотел изобрести велосипед, чтобы самому разобраться, как, что и почему делается при решении такой задачи.

[Dale]

Так всё может закончиться выбором одного из существующих решений

Не обязательно. Целью обзора может быть заимствование удачных идей для реализации в нашей конструкции, а также избежание чужих граблей.

Насколько я понял, x77 хотел изобрести велосипед, чтобы самому разобраться, как, что и почему делается при решении такой задачи.

Тоже вполне реальная и практичная цель проекта: освоить на практике такие-то технологии, научиться тому-то, разобраться в такой-то элементной базе, натаскать команду на совместную удаленную работу... Не обязательно добиваться коммерческого успеха или превзойти все имеющиеся аналоги.  

Главное сейчас - сначала зафиксировать, что, как и для чего будем делать, чтобы не получилось, что видений проекта (и его воплощений) столько же, сколько участников, или даже больше. А уже потом постепенно двигаться к этой цели.

[Ochkarik]

В принципе все пункты правильные, только IMHO некоторые находятся не на своих местах. Например, обзор существующих решений делается после ТЗ, а хорошо бы с него начать.

ТЗ тут в общих словах оговорено в первых постах темы. в качестве основного лейтмотива вполне думаю подойдет. а уточнить его можно как раз по мотивам обзора существующих аналогов)
у нас ТЗ всегда расплывчатые были... хотя тоже головная боль)

В п.3 функциональная схема соседствует со сценариями, а по логике должна разрабатываться для их реализации, т.е. после, ну и прочие причинно-следственные связи не везде соблюдены.

пожалуй... я пока коротенько и прикидочно)

модель прецедентов (Use Case) и V-модель, что посоветуете почитать, что нибудь толковое, не сильно длинное и унылое, желательно на русском?)
[/quote]

[Dale]

модель прецедентов (Use Case) и V-модель, что посоветуете почитать, что нибудь толковое, не сильно длинное и унылое, желательно на русском?)

По Use Case - любой букварь по UML, их сейчас немерено, или вот эту книгу: https://forum.shelek.ru/index.php/topic,26526.msg260714.html#msg260714

По V-модели даже затрудняюсь с ходу что-нибудь конкретное посоветовать, попадалась в нескольких источниках, но навскидку не найду; наверное, надо бы черкнуть об этом хотя бы несколько строк в нашей Вики...

P.S. Коллеги растащили чуть ли не всю книжную полку. Вот среди уцелевших остатков нашел неплохую книгу: Кендалл Скотт, "Унифицированный процесс. Основные концепции". Глава 2, "Технологический процесс управления требованиями", как раз посвящена анализу прецедентов.

P.P.S. Вот нашел у нас статью по теме: https://club.shelek.ru/viewart.php?id=232 . Там очень сжато, но в конце список литературы.

[Dale]

http://ru.wikipedia.org/wiki/V-Model

Вот еще в одной статье попалась неплохая иллюстрация, которая вполне отражает суть:

[Dimka]

Vision про то, что мы тут все вместе собрались, чтобы ... и построить светлое будущее, я пропущу.

Никто не забыт и ничто не забыто? Можно детализировать?

В дальнейшем каждая деталь, каждая feature должна ложиться в матрицу этих use case.

[Dale]

Я бы еще добавил актора "злоумышленник" и прецеденты, связанные с попыткой несанкционированного проникновения: подбор кода замка, перебор электронных ключей и т.п.

[Dimka]

Dale, согласен.

А вот всякие "дети" и т.п. действующие лица нужны? Для них предполагается какая-то специфика? Стоит ли разделять "хозяин дома" и "поставщик"?

[Dale]

И еще. Попавший под неожиданное сокращение Vision помимо прочего должен установить границы проекта, например: используются ли в данной версии (или если нет, то планируется ли к использованию в дальнейшем) домофон, RFID, биометрические датчики, связь с сигнализацией, системой "умного дома" и т.п. От таких деталей может довольно сильно измениться набор прецедентов и их сценарии, а также архитектура системы в целом.

IMHO перепрыгивание начальных этапов даст сегодня мизерный выигрыш в несколько дней, но потом может выйти боком.

Добавлено через 5 минут и 29 секунд:

А вот всякие "дети" и т.п. действующие лица нужны? Для них предполагается какая-то специфика?

Можно заложить на будущее, к примеру, маленькую дверцу для кошек, которая срабатывает на радиометку на ошейнике и не открывается для чужих.

Стоит ли разделять "хозяин дома" и "поставщик"?

Имеет смысл, чтобы ограничить лишний доступ к электронной начинке для чайников.

[Dimka]

используются ли в данной версии (или если нет, то планируется ли к использованию в дальнейшем) домофон, RFID, биометрические датчики, связь с сигнализацией, системой "умного дома" и т.п.

Рискну сказать за x77 и RXL - нет. RFID под кожу хозяину, датчики движения, дверца для кота и т.п. - это замечательно, как и все наполеоновские планы, только в реальности разумнее поступательное развитие - сделать что-нибудь попроще, но сделать, а потом уже, взяв за основу, переходить к версии 2.0. В противном случае не будет ничего.

Но отказ от такого обзора не мешает разработать архитектуру, позволяющую нагружать систему опциями. Слабым местом здесь может оказаться выбор железа, которое не сможет справиться с потребностями возможных опций. Однако архитектура от железа не зависит.

Вот смотри:

Уже меня терзают сомнения, что здесь что-то не так. Основное сомнение заключается в следующем: да, злоумышленник и хозяин дома - разные действующие лица с разными намерениями. Но система об этом априори не знает, она должна сама уметь определять, кто есть кто. А зачем? Что она может сделать в ответ? Ну если есть сигнализация - сигнализировать. Может заблокировать все электронные способы открытия, чтобы можно было открыть только ключом вручную. Но от отмычки уже ничего не поможет, и система даже не сумеет распознать такую ситуацию.

По-моему это надо упрощать.

[Dale]

злоумышленник и хозяин дома - разные действующие лица с разными намерениями. Но система об этом априори не знает, она должна сама уметь определять, кто есть кто. А зачем? Что она может сделать в ответ?

Если это, например, подбор кода замка, то система вполне может его распознать и максимально затруднить. Скажем, давая одну попытку в минуту. Имея 60 попыток в час, не разгуляешься. То же самое при попытке открыть чужой "таблеткой" - следующая будет распознаваться лишь после тайм-аута.

Глупо спроектированная система может, наоборот, максимально облегчить подбор, если будет давать отбой после первой же неправильно введенной цифры. Мне еще попадалась такая небольшая хитрость: после правильно введенного кода ждать несколько секунд, и если ничего не было нажато, только тогда открывать. Тот, кто подбирает код, даже случайно набрав правильную комбинацию, не узнает о совпадении и следующим же нажатием все испортит.

от отмычки уже ничего не поможет, и система даже не сумеет распознать такую ситуацию.

Система вполне может распознать аварийное открытие двери ключом (или взломом) без авторизации и потребовать в кратчайший срок ввести код или приложить "таблетку", иначе сработает сигнализация.

[Ochkarik]

Система вполне может распознать аварийное открытие двери ключом (или взломом) без авторизации и потребовать в кратчайший срок ввести код или приложить "таблетку", иначе сработает сигнализация.

вариант не очень: отвалился провод клавиатуры (кстати ее кажется пока не рассматривали) или таблетки(контакты окислились)
-> открыл ключом, кнопку нажать не можешь, сигнализацию выключить нечем. значит при таком варианте надо предусматривать хотя бы два  способа отключения сигнализации.
да, насчет клавиатуры - пока ее в проекте не было, по-моему? что предлагаете -  клавиатура внешняя или внутренняя?
кстати сигнализацию можно и на телефон завести.... но это уже другой бюджет.

[Dale]

вариант не очень: отвалился провод клавиатуры (кстати ее кажется пока не рассматривали) или таблетки(контакты окислились)

Это вполне можно сделать на собственной клавиатуре пульта девайса, а не на наружной, которую и разбить могут. (Кстати, шантрапа развлекается тем, что лупит электрошокером в гнезда для таблеток). И гнездо для таблетки можно на нем же установить, чтобы слушался только хозяина. Маловероятно, что обе клавиатуры/гнезда вйдут из строя одновременно.

Но это, конечно, более комплексная охранная система получается, чем просто дверной замок с электромагнитом. Потому-то и необходимо предельно четко определить границы перед проектированием.

[Dimka]

Vision должен быть документом с позитивными утверждениями, иначе перечисление всего, что не войдёт в систему будет бесконечным и займёт бесконечное время.

А вот отработка сценариев действия/бездействия системы - это уже более поздний этап.

По-моему, формулировки
"Программируемый

дверной замок с электромагнитом

"
для Vision в данном случае достаточно. Это исключает все остальные варианты Достаточно обозначить, что это не охранная система, а лишь замок. Как это и было обозначено в начале x77.

Поэтому предлагаю остановиться на варианте

[Ochkarik]

Dimka, x77 хотел еще возможность дистанционного открытия двери посетителям, лежа в джакузи)
и не пойму, по этой схеме -  хозяин не может быть посетителем? то есть открывать замок снаружи? или в этот момент он не является "хозяином дома"?

PS "хозяин дома" или "хозяин - дома"?)))))

PPS еще. возможно версию 2.0 можно делать будет делать программно, если в железо заложить хотя бы на 10-20% больше необходимого.
перерабатывать железо по моему опыту - это как правило фактически заново пройти полный цикл разработки.
объясните, можно ли на диаграммах обозначать потенциальные возможности? которыми впринципе можно пожертвовать, если они значительно повышают трудоемкость.

[Dimka]

или в этот момент он не является "хозяином дома"?

Замок телепатией не обладает.

Но в общем ты прав: хозяин - это тот, кто внутри что-то делает, а посетитель - снаружи.

Открытие двери из джакузи - это что-то типа домофона, заведённого в джакузи. Просто кнопка без контроля того, кто стоит за дверью, будет малополезной.

объясните, можно ли на диаграммах обозначать потенциальные возможности? которыми впринципе можно пожертвовать, если они значительно повышают трудоемкость.

Берёшь и рисуешь. Специального обозначения нет - можно стереотип завести и им подписывать.

[RXL]

Клавиатура не планируется.

Защита от электрошокера и просто от разряда статического электричества предусматривается в схеме.

[Dale]

и не пойму, по этой схеме -  хозяин не может быть посетителем? то есть открывать замок снаружи? или в этот момент он не является "хозяином дома"?

В UML применяется отношение обобщения (подобие наследования в ООП). Если провести незакрашенную стрелку от Хозяина к Посетителю, это означает, что Хозяин является частным случаем Посетителя, т.е. может делать все то же самое, что и Посетитель, плюс особые хозяйские фичи.

объясните, можно ли на диаграммах обозначать потенциальные возможности? которыми впринципе можно пожертвовать, если они значительно повышают трудоемкость.

В UML нет такого готового встроенного средства, только стереотипы или комментарии. Обычно это делается несколько иначе: в спецификациях требований каждому требованию приписывается атрибут, который может принимать несколько значений (наиболее типичен набор из трех: обязательное, желательное, необязательное).

Все обязательные непременно попадают в релиз, без них продукт не считается полноценным.

Желательные реализуются, если проект укладывается во временные рамки и остается свободное время (есть и такое суеверие среди программистов, настроенных оптимистично).
 
Что касается необязательных, в эту категорию отправляются требования, до которых почти наверняка в этой версии не дойдут руки, но и забыть о них не хотелось бы; в перспективе они попадут в план одной из следующих версий, если до них дойдет дело, в качестве обязательных или желательных.

[Dimka]

В UML применяется отношение обобщения (подобие наследования в ООП). Если провести незакрашенную стрелку от Хозяина к Посетителю, это означает, что Хозяин является частным случаем Посетителя, т.е. может делать все то же самое, что и Посетитель, плюс особые хозяйские фичи.

В данном случае не подходит. Т.к. "Хозяин" не наследует от "Посетителя" "Вандализм".

Если использовать этот подход, нужно выделение из "Посетителя" его разновидностей: "Хозяина", "Злоумышленника" и ещё кого-то. Но выше я изложил свой скепсис по этому поводу: это интересно в социологическом плане, но совершенно неинтересно с точки зрения решаемой задачи.

[RXL]

Давайте не разделять на множество разных пользователей. Хозяин тоже с пьяну может захотеть навредить.

[Алексей++]

RXL, Игорь то ? ))

[Dimka]

Давайте не разделять на множество разных пользователей. Хозяин тоже с пьяну может захотеть навредить.

Тогда скажи, нужен ли use case "Попытка взлома"? Типа блокировки на минуту после 3-х неудачных попыток и т.п.

[RXL]

Думаю, что не нужен. Посуди сам:
* Карта Wiegand-26 - это 24-битный программируемый поставщиком индентификатор.
* Таблетка DS1990A - это 48-битный уникальный, одноразово программируемый при производстве, идентификатор.
Перебирать их бессмысленно, особенно учитывая медленную работу этих устройств и большой промежуток между циклами чтения.

[Ochkarik]

RXL, а большой таймаут может быть?