Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #150 : 08-08-2011 19:46 » |
|
Игорь хочет карточки. Я считаю, что таблетка удобнее, т.к. ее можно повесить на связку ключей и если электричества нет, то откроешь ключом, когда как карточка отдельно от ключей и их можно просто забыть. А "и того, и другого - и можно без хлеба"? Что я ещё хочу сказать о жизни. Одиночный разработчик все детали может, если ему хочется, держать в голове. Но даже ему лучше записывать - чтобы не забылось. В группе это уже совсем невозможно, поскольку у каждого свои мозги. Каждый субъективно выбирает из множества требований те, которые считает наиболее важными - он про них хорошо помнит и ради их сохранности готов подзабыть или ненароком поменять менее важные требования. Беда в том, что у каждого в группе свои предпочтения, поэтому неминуемо в головах общая картина начинает размываться и рассогласовываться. Бумажка - это связующее звено. Периодически её надо коллективно перечитывать и обсуждать, чтобы восстановить единство картины проекта у всех членов группы. Вместо бумажки в группе может быть идеолог - его задача ходить и "разговоры разговаривать" со всеми, пропуская через себя все мнения и передавая всем эти мнения; или для особо маленькой группы - регулярные разговоры в общем кругу. Ещё один вариант - ведущий, тогда проект он разрабатывает как бы единолично, а остальные от него получают конкретные задания; хотя ведущий с остальными может что-то обсуждать, вся ответственность за целостность лежит на нём, поэтому он может позволить себе какие-то детали держать в своей голове и не парится по поводу того, все ли эти детали знают. Без ведущего - обязанность каждого следить за собой и всеми остальными, чтобы не возникало разных пониманий. Поэтому фиксация всяких мелочей и подробностей для группы жизненно необходима - она обеспечивает единство представления о проекте. На это стоит тратить усилия, это очень важно для группы/команды, занятой совместной работой на общую цель, но с разделением труда и ролей.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
RXL
|
|
« Ответ #151 : 08-08-2011 19:52 » |
|
Да-да. Хочешь - карточку, хочешь - таблетку, хочешь - все сразу, а можно и без всего. Добавлено через 6 минут и 27 секунд:Так с чего же начнем? Уточняем спецификацию и расписываем алгоритмы поведения устройства? Добавлено через 6 минут и 45 секунд:У нас уже есть трекер: http://redmine.shelek.su/projects/vu-lock-controllerПроект открытый - читать можно без регистрации. Желающие принять участия - прошу зарегистрироваться и сообщить свои логины в ЛС для прикрепления к проекту и роль на трекере (менеджер, разработчик). При логине пишите там осмысленные ФИО - мусор я периодически баню, т.к. иначе его не определишь. SVN так же открыт для чтения. Для записи мне нужен произвольный логин/пароль в ЛС. Так получилось, что я вроде как выполняю роль ведущего. Мне это не очень нравится, т.к. хотелось бы в процессе освоить новые для себя технологии и инструменты и нужен если не ведущий (если ни у кого не возникнет такого желания), то хотя бы совместный ведущий.
|
|
« Последнее редактирование: 08-08-2011 20:12 от RXL »
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Ochkarik
|
|
« Ответ #152 : 08-08-2011 20:14 » |
|
все бы вам резать!) тут имхо не резать надо, а аккуратно скопипастить по подразделам (к примеру): 1. ТЗ 2. Обзор существующих изделий 3. Разработка функциональной схемы и сценариев работы в различных режимах(с точки зрения пользователя) 4. Разработка алгоритмов работы отдельных модулей 5. Разработка протоколов обмена между отдельными модулями (что, когда и кто куда передает - информационная составляющая) 6. Выбор и обоснование аппаратной реализации 7. Программная реализация 8. Тестирование отдельных модулей 9. Тестирование устройства в целом
я это как-то так вижу... поправьте если ошибаюсь.
|
|
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
Dale
|
|
« Ответ #153 : 08-08-2011 20:33 » |
|
Поскольку проект некоммерческий, он вполне может обойтись без ТЗ. Настоящее ТЗ изобилует бюрократией и бухгалтерией чуть менее чем полностью.
Что сейчас действительно необходимо, так это сбор и обработка бизнес-требований. Из них будет следовать все остальное.
|
|
« Последнее редактирование: 08-08-2011 20:35 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Ochkarik
|
|
« Ответ #154 : 08-08-2011 20:39 » |
|
Dale, ну я не ГОСТовское ТЗ имел в виду) именно - бизнес) в остальном - есть недочеты?
|
|
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
Dale
|
|
« Ответ #155 : 08-08-2011 21:18 » |
|
В принципе все пункты правильные, только IMHO некоторые находятся не на своих местах. Например, обзор существующих решений делается после ТЗ, а хорошо бы с него начать. В п.3 функциональная схема соседствует со сценариями, а по логике должна разрабатываться для их реализации, т.е. после, ну и прочие причинно-следственные связи не везде соблюдены.
Я обычно строю проекты в таком порядке:
1. Сбор бизнес-требований. 2. Их обработка и выпуск документа Vision (см. ReadySET). 3. Сбор пользовательских требований. 4. Выпуск спецификации требований, в т.ч. функциональных, на основе модели прецедентов (Use Case). 5. Разработка приемочных тестов на основе п.4.
Ну и так далее, по давно накатанной колее с использованием V-модели (у меня к ней давняя симпатия).
|
|
« Последнее редактирование: 09-08-2011 06:41 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #156 : 09-08-2011 07:23 » |
|
Например, обзор существующих решений делается после ТЗ, а хорошо бы с него начать. Так всё может закончиться выбором одного из существующих решений Насколько я понял, x77 хотел изобрести велосипед, чтобы самому разобраться, как, что и почему делается при решении такой задачи.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
Dale
|
|
« Ответ #157 : 09-08-2011 07:37 » |
|
Так всё может закончиться выбором одного из существующих решений Не обязательно. Целью обзора может быть заимствование удачных идей для реализации в нашей конструкции, а также избежание чужих граблей. Насколько я понял, x77 хотел изобрести велосипед, чтобы самому разобраться, как, что и почему делается при решении такой задачи. Тоже вполне реальная и практичная цель проекта: освоить на практике такие-то технологии, научиться тому-то, разобраться в такой-то элементной базе, натаскать команду на совместную удаленную работу... Не обязательно добиваться коммерческого успеха или превзойти все имеющиеся аналоги. Главное сейчас - сначала зафиксировать, что, как и для чего будем делать, чтобы не получилось, что видений проекта (и его воплощений) столько же, сколько участников, или даже больше. А уже потом постепенно двигаться к этой цели.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Ochkarik
|
|
« Ответ #158 : 09-08-2011 08:20 » |
|
В принципе все пункты правильные, только IMHO некоторые находятся не на своих местах. Например, обзор существующих решений делается после ТЗ, а хорошо бы с него начать. ТЗ тут в общих словах оговорено в первых постах темы. в качестве основного лейтмотива вполне думаю подойдет. а уточнить его можно как раз по мотивам обзора существующих аналогов) у нас ТЗ всегда расплывчатые были... хотя тоже головная боль) В п.3 функциональная схема соседствует со сценариями, а по логике должна разрабатываться для их реализации, т.е. после, ну и прочие причинно-следственные связи не везде соблюдены. пожалуй... я пока коротенько и прикидочно) модель прецедентов (Use Case) и V-модель, что посоветуете почитать, что нибудь толковое, не сильно длинное и унылое, желательно на русском?) [/quote]
|
|
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
Dale
|
|
« Ответ #159 : 09-08-2011 09:04 » |
|
модель прецедентов (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 . Там очень сжато, но в конце список литературы.
|
|
« Последнее редактирование: 09-08-2011 09:15 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #160 : 09-08-2011 11:04 » |
|
http://ru.wikipedia.org/wiki/V-ModelВот еще в одной статье попалась неплохая иллюстрация, которая вполне отражает суть:
|
V.PNG (32.41 Кб - загружено 1711 раз.)
|
« Последнее редактирование: 09-08-2011 12:35 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #161 : 09-08-2011 11:41 » |
|
Vision про то, что мы тут все вместе собрались, чтобы ... и построить светлое будущее, я пропущу. Никто не забыт и ничто не забыто? Можно детализировать? В дальнейшем каждая деталь, каждая feature должна ложиться в матрицу этих use case.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
Dale
|
|
« Ответ #162 : 09-08-2011 11:47 » |
|
Я бы еще добавил актора "злоумышленник" и прецеденты, связанные с попыткой несанкционированного проникновения: подбор кода замка, перебор электронных ключей и т.п.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #163 : 09-08-2011 11:57 » |
|
Dale, согласен.
А вот всякие "дети" и т.п. действующие лица нужны? Для них предполагается какая-то специфика? Стоит ли разделять "хозяин дома" и "поставщик"?
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
Dale
|
|
« Ответ #164 : 09-08-2011 11:59 » |
|
И еще. Попавший под неожиданное сокращение Vision помимо прочего должен установить границы проекта, например: используются ли в данной версии (или если нет, то планируется ли к использованию в дальнейшем) домофон, RFID, биометрические датчики, связь с сигнализацией, системой "умного дома" и т.п. От таких деталей может довольно сильно измениться набор прецедентов и их сценарии, а также архитектура системы в целом. IMHO перепрыгивание начальных этапов даст сегодня мизерный выигрыш в несколько дней, но потом может выйти боком. Добавлено через 5 минут и 29 секунд:А вот всякие "дети" и т.п. действующие лица нужны? Для них предполагается какая-то специфика? Можно заложить на будущее, к примеру, маленькую дверцу для кошек, которая срабатывает на радиометку на ошейнике и не открывается для чужих. Стоит ли разделять "хозяин дома" и "поставщик"? Имеет смысл, чтобы ограничить лишний доступ к электронной начинке для чайников.
|
|
« Последнее редактирование: 09-08-2011 12:04 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #165 : 09-08-2011 12:35 » |
|
используются ли в данной версии (или если нет, то планируется ли к использованию в дальнейшем) домофон, RFID, биометрические датчики, связь с сигнализацией, системой "умного дома" и т.п. Рискну сказать за x77 и RXL - нет. RFID под кожу хозяину, датчики движения, дверца для кота и т.п. - это замечательно, как и все наполеоновские планы, только в реальности разумнее поступательное развитие - сделать что-нибудь попроще, но сделать, а потом уже, взяв за основу, переходить к версии 2.0. В противном случае не будет ничего. Но отказ от такого обзора не мешает разработать архитектуру, позволяющую нагружать систему опциями. Слабым местом здесь может оказаться выбор железа, которое не сможет справиться с потребностями возможных опций. Однако архитектура от железа не зависит. Вот смотри: Уже меня терзают сомнения, что здесь что-то не так. Основное сомнение заключается в следующем: да, злоумышленник и хозяин дома - разные действующие лица с разными намерениями. Но система об этом априори не знает, она должна сама уметь определять, кто есть кто. А зачем? Что она может сделать в ответ? Ну если есть сигнализация - сигнализировать. Может заблокировать все электронные способы открытия, чтобы можно было открыть только ключом вручную. Но от отмычки уже ничего не поможет, и система даже не сумеет распознать такую ситуацию. По-моему это надо упрощать.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
Dale
|
|
« Ответ #166 : 09-08-2011 12:51 » |
|
злоумышленник и хозяин дома - разные действующие лица с разными намерениями. Но система об этом априори не знает, она должна сама уметь определять, кто есть кто. А зачем? Что она может сделать в ответ? Если это, например, подбор кода замка, то система вполне может его распознать и максимально затруднить. Скажем, давая одну попытку в минуту. Имея 60 попыток в час, не разгуляешься. То же самое при попытке открыть чужой "таблеткой" - следующая будет распознаваться лишь после тайм-аута. Глупо спроектированная система может, наоборот, максимально облегчить подбор, если будет давать отбой после первой же неправильно введенной цифры. Мне еще попадалась такая небольшая хитрость: после правильно введенного кода ждать несколько секунд, и если ничего не было нажато, только тогда открывать. Тот, кто подбирает код, даже случайно набрав правильную комбинацию, не узнает о совпадении и следующим же нажатием все испортит. от отмычки уже ничего не поможет, и система даже не сумеет распознать такую ситуацию. Система вполне может распознать аварийное открытие двери ключом (или взломом) без авторизации и потребовать в кратчайший срок ввести код или приложить "таблетку", иначе сработает сигнализация.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Ochkarik
|
|
« Ответ #167 : 09-08-2011 13:04 » |
|
Система вполне может распознать аварийное открытие двери ключом (или взломом) без авторизации и потребовать в кратчайший срок ввести код или приложить "таблетку", иначе сработает сигнализация.
вариант не очень: отвалился провод клавиатуры (кстати ее кажется пока не рассматривали) или таблетки(контакты окислились) -> открыл ключом, кнопку нажать не можешь, сигнализацию выключить нечем. значит при таком варианте надо предусматривать хотя бы два способа отключения сигнализации. да, насчет клавиатуры - пока ее в проекте не было, по-моему? что предлагаете - клавиатура внешняя или внутренняя? кстати сигнализацию можно и на телефон завести.... но это уже другой бюджет.
|
|
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
Dale
|
|
« Ответ #168 : 09-08-2011 13:15 » |
|
вариант не очень: отвалился провод клавиатуры (кстати ее кажется пока не рассматривали) или таблетки(контакты окислились) Это вполне можно сделать на собственной клавиатуре пульта девайса, а не на наружной, которую и разбить могут. (Кстати, шантрапа развлекается тем, что лупит электрошокером в гнезда для таблеток). И гнездо для таблетки можно на нем же установить, чтобы слушался только хозяина. Маловероятно, что обе клавиатуры/гнезда вйдут из строя одновременно. Но это, конечно, более комплексная охранная система получается, чем просто дверной замок с электромагнитом. Потому-то и необходимо предельно четко определить границы перед проектированием.
|
|
« Последнее редактирование: 09-08-2011 13:17 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #169 : 09-08-2011 13:41 » |
|
Vision должен быть документом с позитивными утверждениями, иначе перечисление всего, что не войдёт в систему будет бесконечным и займёт бесконечное время. А вот отработка сценариев действия/бездействия системы - это уже более поздний этап. По-моему, формулировки "Программируемый дверной замок с электромагнитом " для Vision в данном случае достаточно. Это исключает все остальные варианты Достаточно обозначить, что это не охранная система, а лишь замок. Как это и было обозначено в начале x77. Поэтому предлагаю остановиться на варианте
|
|
« Последнее редактирование: 09-08-2011 13:43 от Dimka »
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
Ochkarik
|
|
« Ответ #170 : 09-08-2011 14:22 » |
|
Dimka, x77 хотел еще возможность дистанционного открытия двери посетителям, лежа в джакузи) и не пойму, по этой схеме - хозяин не может быть посетителем? то есть открывать замок снаружи? или в этот момент он не является "хозяином дома"?
PS "хозяин дома" или "хозяин - дома"?)))))
PPS еще. возможно версию 2.0 можно делать будет делать программно, если в железо заложить хотя бы на 10-20% больше необходимого. перерабатывать железо по моему опыту - это как правило фактически заново пройти полный цикл разработки. объясните, можно ли на диаграммах обозначать потенциальные возможности? которыми впринципе можно пожертвовать, если они значительно повышают трудоемкость.
|
|
« Последнее редактирование: 09-08-2011 14:41 от Ochkarik »
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #171 : 09-08-2011 15:03 » |
|
или в этот момент он не является "хозяином дома"? Замок телепатией не обладает. Но в общем ты прав: хозяин - это тот, кто внутри что-то делает, а посетитель - снаружи. Открытие двери из джакузи - это что-то типа домофона, заведённого в джакузи. Просто кнопка без контроля того, кто стоит за дверью, будет малополезной. объясните, можно ли на диаграммах обозначать потенциальные возможности? которыми впринципе можно пожертвовать, если они значительно повышают трудоемкость. Берёшь и рисуешь. Специального обозначения нет - можно стереотип завести и им подписывать.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
RXL
|
|
« Ответ #172 : 09-08-2011 15:23 » |
|
Клавиатура не планируется.
Защита от электрошокера и просто от разряда статического электричества предусматривается в схеме.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Dale
|
|
« Ответ #173 : 09-08-2011 17:29 » |
|
и не пойму, по этой схеме - хозяин не может быть посетителем? то есть открывать замок снаружи? или в этот момент он не является "хозяином дома"? В UML применяется отношение обобщения (подобие наследования в ООП). Если провести незакрашенную стрелку от Хозяина к Посетителю, это означает, что Хозяин является частным случаем Посетителя, т.е. может делать все то же самое, что и Посетитель, плюс особые хозяйские фичи. объясните, можно ли на диаграммах обозначать потенциальные возможности? которыми впринципе можно пожертвовать, если они значительно повышают трудоемкость. В UML нет такого готового встроенного средства, только стереотипы или комментарии. Обычно это делается несколько иначе: в спецификациях требований каждому требованию приписывается атрибут, который может принимать несколько значений (наиболее типичен набор из трех: обязательное, желательное, необязательное). Все обязательные непременно попадают в релиз, без них продукт не считается полноценным. Желательные реализуются, если проект укладывается во временные рамки и остается свободное время (есть и такое суеверие среди программистов, настроенных оптимистично). Что касается необязательных, в эту категорию отправляются требования, до которых почти наверняка в этой версии не дойдут руки, но и забыть о них не хотелось бы; в перспективе они попадут в план одной из следующих версий, если до них дойдет дело, в качестве обязательных или желательных.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #174 : 09-08-2011 20:14 » |
|
В UML применяется отношение обобщения (подобие наследования в ООП). Если провести незакрашенную стрелку от Хозяина к Посетителю, это означает, что Хозяин является частным случаем Посетителя, т.е. может делать все то же самое, что и Посетитель, плюс особые хозяйские фичи. В данном случае не подходит. Т.к. "Хозяин" не наследует от "Посетителя" "Вандализм". Если использовать этот подход, нужно выделение из "Посетителя" его разновидностей: "Хозяина", "Злоумышленника" и ещё кого-то. Но выше я изложил свой скепсис по этому поводу: это интересно в социологическом плане, но совершенно неинтересно с точки зрения решаемой задачи.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
RXL
|
|
« Ответ #175 : 10-08-2011 05:51 » |
|
Давайте не разделять на множество разных пользователей. Хозяин тоже с пьяну может захотеть навредить.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Алексей++
глобальный и пушистый
Глобальный модератор
Offline
Сообщений: 13
|
|
« Ответ #176 : 10-08-2011 05:56 » |
|
RXL, Игорь то ? ))
|
|
|
Записан
|
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #177 : 10-08-2011 08:01 » |
|
Давайте не разделять на множество разных пользователей. Хозяин тоже с пьяну может захотеть навредить. Тогда скажи, нужен ли use case "Попытка взлома"? Типа блокировки на минуту после 3-х неудачных попыток и т.п.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
RXL
|
|
« Ответ #178 : 10-08-2011 09:59 » |
|
Думаю, что не нужен. Посуди сам: * Карта Wiegand-26 - это 24-битный программируемый поставщиком индентификатор. * Таблетка DS1990A - это 48-битный уникальный, одноразово программируемый при производстве, идентификатор. Перебирать их бессмысленно, особенно учитывая медленную работу этих устройств и большой промежуток между циклами чтения.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Ochkarik
|
|
« Ответ #179 : 10-08-2011 11:12 » |
|
RXL, а большой таймаут может быть?
|
|
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
|