106

Примеры / Re: Сценарий использования выдачи книги

« : 31 Марта 2016, 18:27:08 »

Леонид, это все Ваши инсинуации

Разумеется. Как и все остальные мои посты на форуме. Но исключительно в хорошем смысле этого слова!

107

Примеры / Re: Сценарий использования выдачи книги

« : 31 Марта 2016, 17:26:09 »

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

Регистр по сути и есть один из методов обеспечения историчности.

Не совсем понимаю, что именно имеется ввиду под "регистром". Если что-то вроде журнала "Выдано такому-то до такого-то числа", то тут даже никакого атрибута "допустимый срок" не требуется. "До такого-то числа" вычисляется по правилам, действующим на момент выдачи и не потеряет актуальности при любых последующих изменениях.

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

108

Примеры / Re: ПО для учета посещений пациентами приема

« : 31 Марта 2016, 11:07:35 »

Хочу с вашей помощью или подсказками спроектировать некое программное обеспечение. Очень хочу сам разобраться во всем...

Вернее мне нужны подсказки и направления на этапе проектирования ПО...

Ну, давайте попробуем.

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

Это назначение ПО.

Целью создания ПО является автоматизация учета приема пациентов.

Нет. Давайте попробуем еще раз, это интересный и важный момент "для самостоятельного изучения". Не получится - тогда разберем вместе.

Основные функции программы:
•   Ведение справочника пациентов (добавление/изменение/удаление пациента)

1. Удалять пациентов из справочника нельзя, отчеты не получатся.
2. Само по себе ведение справочника - не основная функция, а вспомогательная. Функция информационного обеспечения. Поэтому начинать с нее список не стоит. Лучше подальше в конец, если нет отдельного списка для вспомогательных функций.

•   Ведение приема (простановка отметки о посещении приема)

Предлагаю "Регистрация факта посещения врача". ПО вести прием не может в принципе, этим занимается врач. Пациент посещает не прием, а врача (а вот процесс посещения пациентом врача для простоты называется "приемом").

•   Отображение пришедших, записанных и не пришедших пациентов

Непонятно, что это. Отчет? А то ж все эти пациенты и в справочнике отображаться будут.

•   Вывод данных о занятых и свободных часах на выбранную дату приема (при записи пациента)

Я бы осмелился предложить формулировку "Предварительная запись пациента на прием".

109

Примеры / Re: Сценарий использования выдачи книги

« : 31 Марта 2016, 10:47:53 »

Интересно, кроме как в России, где то еще возможны никем не оплачиваемые споры такого интеллектуального уровня и эмоционального напряжения?

На забугорных форумах видел то же самое. "В интернете кто-то неправ!" - сила великая.
И почему никем не оплачиваемые? Я вот днем пишу, с работы. Так что оплачиваемые наравне с перекурами, чаепитиями и прочими прогулками по нужде.

110

Примеры / Re: Сценарий использования выдачи книги

« : 30 Марта 2016, 11:33:31 »

Где сказано, что они нужны? Вы смотрели юзкейс?

С ваших слов: "Вы знаете частоту, когда нужны эти даты?". Не "если", а "когда".

Почему частота не принципиальна при выборе считать/хранить?

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

Вы слышали выражение "выводимый атрибут"?

Неоднократно. Правда, не уверен, что мы вкладываем в это выражение идентичный смысл. Какова цель вопроса?

И кто теперь изобретает то, что собеседник не говорил?

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

Вы сможете объяснить, почему не хранить, а считать контрольную дату в библиотечной системе плохо? Шире, чем наклеив ярлычки "популярные грабли", "система-однодневка"? Пока _объяснения_ нет.

Что ж, давайте попробуем на пальцах. Рассмотрим период работы сферической библиотеки с января 2015 по июнь 2015.

Выдает она книги на руки, какую-то часть из них нерадивые читатели задерживают. Согласно приказу от, гм, 11.07.2004г, допустимый срок удержания книги на руках составляет 21 день. Этот момент учтен в библиотечной ИС и она исправно штампует ежемесячные, квартальные, полугодовые и годовые отчеты о количестве случаев нарушений сроков, которые идут на подпись директору и отправляются в вышестоящую инстанцию.

12.03.2015г. библиотека получает новый приказ, в котором допустимый срок удержания книги на руках с 01.04.2015г. увеличивается до 48 дней.  Автоматизаторы быстренько допиливают математику ИС, и со второго квартала она так же исправно считает просрочки по новым правилам.

Гром грянул 07.07.2015, когда директор библиотеки вернулся с ковра вышестоящего начальника враскоряку. Оказалось, что полугодовой отчет, который он собственноручно подписал и сдал, никак не бьется с квартальными и ежемесячными. Если просто сложить все помесячно, получается больше, чем в полугодовом. Директору библиотеки объявили выговор за попутку сокрытия недостатков в работе вверенного заведения, лишили премии и заставили прилюдно оправдываться. Директор очень зол на всех.

А ларчик, как нетрудно догадаться, открывался просто. Полугодовой отчет был сформирован по новым правилам, в то время как предыдущий квартальный (и первые три ежемесячных) формировались по старым, более жестким.


Теперь можно заменить сферическую библиотеку на сферичекое Управление ГИБДД, а книги - на госномера. Или библиотеку на ФМС, а книги - на разрешения на работу. Вне зависимости от предметной области, блестящее решение автоматизаторов приведет к одним и тем же результатам. Вполне вероятно, что даже финансовым.

Где я предлагаю "безграничные возможности"?

"Если новичку искусственно сужать пространство выбора, он не наберется опыта."

Искусственно сужать пространство выбора = ограничивать возможности получения им опыта. Не сужать пространство = не ограничивать возможности. Т.е. оставить их безграничными. Нет?

Вернёмся назад. Из двух предложенных альтернатив безапелляционно вырезается одна и объявляется плохой.

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

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

Так если Вам все прозрачно и ясно - чего мы тут целый скролл исписали?

111

Примеры / Re: Сценарий использования выдачи книги

« : 30 Марта 2016, 10:56:54 »

Эдуард, вроде все так и есть. Вопросившему ответили, он поблагодарил. Дальше "профессионалы" (кавычки - это я о себе) роются там, где кроется дьявол. Если наш топикстартер осилит этот диалог (при условии, что он еще с нами), наверняка вынесет что-то для себя полезное. Ну а мы просто развлечемся.

112

Примеры / Re: Сценарий использования выдачи книги

« : 29 Марта 2016, 17:45:25 »

Вы знаете частоту, когда нужны эти даты?

Достаточно того, что они нужны. Раз в год или каждые 15 минут - уже не принципиально.

Вы уверены, что сразу станет плохо, как только начнут менять?

Да. Любое изменение метода расчета приведет к утрате адекватности данных за предыдущие периоды.

Этот эффект можно компенсировать, вводя противовес в виде приличной системы версионирования методов расчета, формирования отчетности с плавающей математикой и/или иных костылей. Главное - ни в коем случае не оснащать объекты учета нужными атрибутами.

Как менять?

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

Можно привести пример изменения [для библиотеки], не критичного для метода. Можно привести пример критичного. Вы какое изменение предпочтёте?

Зависит от того, с какой целью Вы собрались привести пример. Мне сие неведомо, так что на Ваше усмотрение.

Если новичку искусственно сужать пространство выбора, он не наберется опыта. Он будет воспроизводить шаблон, спущенный свыше, и всё.

Новичку надо объяснять, "что такое хорошо, что такое плохо". Или предлагаете предоставить новичкам  безграничные возможности учиться на собственных ошибках, невзирая на стоимость этого "обучения" для проектной команды (прежде всего, со стороны исполнителя) и результатов работы в целом?

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

Ничего не понял, если честно. Зачем мне править какие-то ярлыки, которые только Вы и видите?

113

Примеры / Re: Сценарий использования выдачи книги

« : 29 Марта 2016, 15:56:31 »

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

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

Учить надо оценивать ситуацию а потом, исходя из неё, решать, что хорошо, а что плохо.

Новичку нечем оценивать ситуацию. Наберется опыта - сможет, а пока лучше прислушиваться к тому, чему учат.

И не надо учить, малюя ярлыки: считать всегда плохо, всегда нужно хранить.

Это уже Ваше изобретение, я такого не утверждал.

114

Примеры / Re: Сценарий использования выдачи книги

« : 29 Марта 2016, 14:49:49 »

Чтобы вернуться в реальный контекст.

Что-то Вы меня совсем не понимаете. Библиотека не при чем. Метод обработки данных, при котором данные пересчитываются каждый раз, когда понадобятся, в надежде на то, что правила пересчета заданы раз и навсегда - плохой метод*. Этому надо учить новичков.

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

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

* за исключением систем-однодневок.

115

Примеры / Re: Сценарий использования выдачи книги

« : 29 Марта 2016, 13:24:27 »

При решении учебных примеров?

В работе.

Вы найдите библиотечного ИТшника и обсудите с ним задачу. Уверен, он покрутит пальцем у виска.

Зачем мне это?

Если мы всё ещё играем в библиотеку, откуда знать, важны ли сроки возврата книг вообще?
...
Я не понимаю Вашего подхода.

Библиотеку? Я отметил в рекомендациях подход, применение которого (безотносительно предметной области) делает жизнь и предметных специалистов, и автоматизаторов значительно ярче и богаче. О чем и отписал.

Из двух предложенных альтернатив (двух, чтобы новичок видел, что нет одного "правильного" ответа) Вы вырезаете одну (как-будто другой не было). Вырезали и что теперь?

Разве я могу что-то вырезать из Вашего текста? Я могу разве что ткнуть пальцем в откровенно неудачное решение, приводящее к массе проблем в ближайшем же обозримом будущем (но не сегодня).
Дабы новичок видел, что не все альтернативы одинаково полезны. Может быть, это убережет его от получения личного опыта (и кто знает - может, даже меня от ликвидации последствий его получения новичком).

116

Примеры / Re: Сценарий использования выдачи книги

« : 29 Марта 2016, 11:06:12 »

Другие популярные грабли называются YAGNI.

Согласен. Регулярно сталкиваюсь с последствиями деятельности адептов этой концепции.

117

Для всех / Re: Помогите пожалуйста с тестом «Методология разработки ПО»

« : 29 Марта 2016, 11:02:17 »

ссылка на файл с тестом: http://ifolder.su/44884035

А слабо прямо в тему выложить, дабы не заставлять народ лезть в файлопомойки и совершать иные телодвижения только для того, чтобы удостоиться чести лицезреть предмет вопроса?

118

Задачи студентов / Re: Требования к ПО "Блокнот"

« : 28 Марта 2016, 17:02:42 »

А можно поподробнее?
Чем с точки зрения нынешних методик нагрузочного тестирования...отличается  от

Это вопрос не тестирования. В первом случае задается верхняя планка допустимого количества, во втором нижняя. Второй легким движением руки можно превратить в "Максимальное количество одновременно работающих клиентов больше 99". Звучит.

Как полностью проверить выполнение требования "не меньше 100"? 1.000 - это не меньше 100. 1.000.000 - это не меньше 100. Тут можно разве что договориться с заказчиком и прописать документально, что тестировать будем на конкретно стольки-то пользователях. Которых не меньше 100, разумеется (например, 147). И то это вряд ли спасет от вопросов ревизоров.

119

Задачи студентов / Re: Требования к ПО "Блокнот"

« : 28 Марта 2016, 13:15:57 »

Бизнес-правила
Системой могут пользоваться только сотрудники организации.

А при чем тут бизнес? Это правило про ограничение доступа.

Система работает только с файлами с расширением *.txt

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

Клиент системы может работать только с файлами, расположенными на сервере.
Данные между клиентом и сервером передаются по протоколу FTP

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

Атрибуты качества продукта
Производительность:
1. Максимальное количество одновременно работающих клиентов не меньше 100

Очень плохо. Попрошу продемонстрировать работу для 1.000.000 пользователей. Как покажете?
Рекомендую применять формулировку "до Х..." (в смысле не "дох...", а "до х единиц").

2. Максимальная частота запросов от пользователя (в минуту) не больше 10

Это требование к пользователю?

3. Количество исполняемых транзакций (в минуту) не меньше 50

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

4. Длительность типовых транзакций (операций) не больше 10 секунд

Аналогично. Понятно, что пример утрирован - но если и в реальности будете так писать, посеете ветер. Много ветра.

Доступность:
Коэффициент доступности серверной части не менее 96%
Допустимое время простоя (в час) не более 3 минут
Безопасность:
Вероятность утечки данных в результате сбоя не должна превышать 0.1%
Масштабируемость:
Стоимость десятикратного увеличения мощности системы не должна превышать 400%

Круто. Будьте готовы все это доказать.

Атрибуты качества использования
Скорость обучения пользованию программой должна быть менее 10 минут

Оно как бы не только от вас зависит. А потому - плохое требование.

Удовлетворенность пользователей и средняя оценка продукта должны быть на уровне ожиданий.

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

120

Примеры / Re: Сценарий использования выдачи книги

« : 28 Марта 2016, 12:45:05 »

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

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