Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - SALar

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
136
Друзья,

интересно ваше мнение по спецификации данного варианта использования.

Имя: Просмотреть дневник ученика
ID: 006
Краткое описание: ВИ описывает просмотр расписания, оценок, ДЗ, посещаемости, примечаний в дневнике учеником или родственником
Действующие лица: Ученик
Предусловие:
1.Ученик авторизован в системе
2. Система отображает профиль ученика с его личными данными (ФИО, дата рождения, класс, адрес, телефон, email, ФИО родственников) и тремя опциями: выйти, рейтинг успеваемости, дневник.
Постусловие: Отображено расписание, ДЗ, оценки, посещаемость, примечания в электронном дневнике
Основной поток:
1.Ученик или родственник выбирает опцию ”Дневник”.
2.Система отображает текущую неделю в дневнике, с возможностью перелистывать страницы назад и вперед (предыдущая и следующая неделя), в котором содержится информация о расписании занятий, посещаемости, успеваемости, домашних заданиях и примечаниях.
IMHO: меньше текста - лучше читается.

-----------------------------------------------------
Название: просмотр своего дневника
ОДЛ: ученик, "родитель ученика"
Основной сценарий:
1. ОДЛ отдает команду на просмотр дневника
2. SuD отображает текущую неделю в дневнике (атрибуты страницы смотри в разделе "Описание объектов")

Расширение: есть навигация, позволяющая перемещаться на неделю назад - вперед или переместиться на произвольную неделю.
-- Все. Больше ничего не надо. ----------------------------------------------------

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

137
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 20 Октября 2014, 16:05:32 »
Нашел: http://gaperton.livejournal.com/49867.html
Работать по ГОСТ-у сложно. Очень мало кто способен составить план работы. Под планом понимается "декомпозия конечной цели на промежуточные результавы в терминах критериев завершенности." Не может содержать активностей, исполнителей, трудоемкости и прочего.

138
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 20 Октября 2014, 10:49:57 »
Несколько гипотез:
* http://blog.shumoos.com/archives/288
* У Влада Балина (http://gaperton.livejournal.com/) была интересная статья о работе по ГОСТ
* Кроме ТЗ можно писать кучу Частных ТЗ. Каждое на сотни страниц.

139
Примеры / Re: Подскажите что не так
« : 20 Октября 2014, 10:43:04 »
Посмотрите: https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D1%81%D0%B5%D1%82%D0%BD%D0%B0%D1%8F_%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F
Возможно, немного поможет в классификации.

PS. ISBN где?

140
Не, не, не. Я имею ввиду сценарий:
...
* Пин клавиатура передает ПИН карте
* Какрта валидирует ПИН
...
* Банкомат передает финансовую операцию с присланным HSM-ом случайным числом карте на подпись
* Карта подписывает дайджест операции при помощи ключа, счетчика и случайного числа
* Карта отправляет сообщение с подписью
...
* HSM валидирует подпись

онлайн валидация естественно есть, но только по сети посылается не ПИН и не шифрованный ПИН и не хешированный ПИН. По сети посылается подпись от уникальной комбинации (счетчик защищает от реплай атак). А ПИН проверяет карта. И это правильно, т.к. секьюрно.


> Вообще, в EMV есть несколько способов верификации держателя карты, включающие: онлайн ПИН (проверяется хостом), оффлайн ПИН (проверяется картой), подпись на чеке (проверяется кассиром), без проверки (да, формально это тоже метод верификации, со своим идентификатором

Угу. И еще примерно с десяток способов... Из экзотики - проверка отпечатка пальца, проводимая картой...



141
Григорий, может я чего не помню, но мне казалось, что работа с пином зависит от карты. Если карта чиповая, то пин проверяет карта.

Банкомат лучше разбить на две системы: пин клавиатуру и прочее.
Между банкоматом и процессингом банка еще что-то должно быть. Ну банкомат то необязательно этого же банка.
HSM еще добавьте.

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

142
Сергей, наверное, твой подход правильный. Но в данном случае нужно следовать нотации IDEF0, 

* Средства преобразования
* Люди с их знаниями и умениями (описать требования к квалификации)
Это и есть механизмы

А * Нормы деятельности (ГОСТ-ы, СНИП-ы, инструкции и т.д.)
Управление
Согласен. Нужно следовать IDEF0, давайте следовать IDEF0.

143
IMHO. Лучше не "механизмы", а "средства преобразования".

И мне по прежнему нравится описание, разбитое по следующим группам:
* Материал (вход)
* Продукт (выход)
* Процесс преобразования
* Средства преобразования
* Люди с их знаниями и умениями (описать требования к квалификации)
* Нормы деятельности (ГОСТ-ы, СНИП-ы, инструкции и т.д.)

Пожалуй соглашусь с Эдом, что пар и электроэнергия это "Вход"

144
IMHO
Расположение бизнес-логики. Поддерживать и развивать логику проще, если она на сервере приложений. Меньше даунтайм, проще работа в ветками кода. Это не значит, что совсем нельзя держать логику в СУБД. Это означает, что получив на начальной стадии плюс в скорости разработки в СУБД вы потом просядете на поддержке.
Чем более сложным предполагается приложение тем больше доводов за хранение логики на сервере приложений.


Нагрузка на БД целевой системы - порядка 150000 запросов в сутки, количество пользователей, работающих с веб-интерфейсом - порядка 20 сотрудников.
Может я чего не понимаю, но это совсем небольшая нагрузка. Даже для серверов 15-летней давности это было весьма и весьма подъемно. В 2001 делал тестирование производительности для некоей системы. Без всякой оптимизации, да и с неудачной архитектурой. На слабых серверах система спокойно держала более 100 запросов в секунду (запросы на чтение). В 2008 по просьбе одного из сайтов проводили оптимизацию. Сервера также были не ахти (по тем временам). Несложной манипуляцией подняли производительность с 2 500 до 5 000 запросов в секунду. И никакого Оракла. И никакого кластера.
А 20 бизнес пользователей... Ну это 2000 год и низкопроизводительные FileMaker или Acces.
Наверное, я чего то не понимаю...

145
Да ладно вам. Все же знают, что правильный способ разработки: "Фигак, фигак и в продакшен."

146
Согласен с Леонидом. И в том что анонс "не очень", и в области применения IDEF0,  и в остальном.

147
Сергей,
 так может все-таки подискутируем на ЛАФ? Доклад+дискуссия.
По поводу доклада - это скорее к программному комитету. Могу заявить и эту тему.

148
"Обновление БД", "Сканирование не системы, но скаченного файла". "Сканирование открытого сайта", "отправка отчета разработчику" и т.д.
Если несильно напрячься, то 20-50 ВИ написать можно

149
Всем привет!
Подскажите, в какой нотации сделаны диаграммы?
Не похожи на EPC / BPMN..
EPC / BPMN хороши при описании текущего процесса и проектировании будущего. При этом программное обеспечение внедрять совсем необязательно. Вполне можно ограничиться бумажной механизацией. Часто так в разы выгоднее. Не поверите, но даже некоторые программисты это поняли. И используют доску со стикерами вместо трекера задач.

А вот для описания спецификации требований к ПО часто удобнее использовать другие диаграммы. В документе один из вариантов диаграммы состояний (из UML).

150
Да нет никаких проблем. Вы поделились примером, а мне интересно, чем именно он Вас привлекает.
Я с первого взгляда не могу найти в нем каких-либо достоинств по сравнению с подачей по ГОСТ 34 (в отличие от недостатков), поэтому и спрашиваю. Не хотелось бы упустить что-нибудь интересное и потенциально полезное.
Меня он привлекает тем, что образцов документации почти нет. Приложите нормальное ТЗ по 34 - всем будет профит. И еще образец по <...> и по <...>. И по RUP. И по MSF. И по Creestal Orange. И по ...

Я с первого взгляда не могу найти в нем каких-либо достоинств по сравнению с подачей по ГОСТ 34 (в отличие от недостатков),
А вот давайте не будем путать теплое с мягким. Это принципиально разные документы.
34.602 выдвигает требования к системе, как совокупности навыков пользователей системы, нормативной документации, описанию требований к продуктам и исходным материалам и к процессу преобразования материалов в продукт. Ну и еще, немного, к средству преобразования. Коим, кроме ПО, будет еще аппаратная часть, а так же, возможно ручки, столы, пневмопочта, шредеры, лопаты, вилы и прочее.

А здесь всего навсего SRS. Т.е. следующий за 34.602 документ, раскрывающий лишь малую часть ТЗ.

PS. Может на ЛАФ?

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »