Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Когда вы написали и утвердили программу и методику испытаний.
Технического, метрологического, организационного и методического обеспечения у игры не существует.
Математическое, информационное и лингвистическое обеспечение раскрываются в геймплее. Творческая раскладка геймплея на эти 3 категории скорее всего ничего не даст.
Смотрим дальше,
Как это маппировать на игру? Я не понимаю.
Андрей, ещё раз — мобильная игра не является автоматизированной системой. Она является программным обеспечением, программным продуктом со своими существенными особенностями, отличающими её от других категорий программных продуктов.
Вся смысловая риторика автоматизации как процесса замены участков человеческой деятельности автоматизированными и автоматическими функциями...
...с сокращением затрат (времени, усилий и/или стоимости) совершенно не применима к игре.
Игра наоборот стремится увеличить время и затраты в целом, проводимые в игре, что делает её более похожей на медиапродукцию.
Единственное место, где может быть полезен ГОСТ 34 — при разработке бэкенда для системы, который будет представлять собой полноценную автоматизированную систему.
Давайте, в конце концов, посмотрим, что из основного состава ГОСТ 34.602 может хоть в принципе иметь какое-то отношение к мобильной игре:
2.6.1. В подразделе «Требования к системе в целом» указывают:
1. требования к структуре и функционированию системы; — в лучшем случае это геймплей + карта навигации + структура игрового мира. но как именно называние их таким образом поможет — не ясно
2. требования к численности и квалификации персонала системы и режиму его работы; — не применимо, у самой игры персонала нет
3. показатели назначения; — ну да, игра должна затягивать и приносить миллион долларов в месяц. но это не задание для программиста
5. требования безопасности; — не применимо, если не считать ограничения на использование мельтешаших цветов и недопущение развития нервных расстройств, припадков эпилепсии и депривации сна. но чтобы это правильно сформулировать, нужно знать хоть что-то из эргономики, когнитивной психологии и социологии
6. требования к эргономике и технической эстетике; — даже ISO 9241/9126/25010 практически ничего не говорят о том, как задавать требования к графическому дизайну. я тоже не знаю
7. требования к транспортабельности для подвижных АС; — не применимо
8. требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; — не применимо
9. требования к защите информации от несанкционированного доступа; — любой продакт с минимальным опытом игры не забудет, что аккаунт должен быть с паролем
11. требования к защите от влияния внешних воздействий; — не применимо или нужно подходить очень творчески
13. требования по стандартизации и унификации; — есть в стандарте на софт
как после обследования понять что все(нужные) требования собраны?
Т.е как проводить тестирование, проверку требований?
Какие документы кроме Отчета об обследовании могут быть написаны не забегая сразу до ТЗ.
Я понимаю что в целом в обследовании итерационный подход, пока не будет достигнут определенный уровень качества требований аналитиком или менеджером, но как этот уровень определяется?
Полностью согласен. Хотя необходимость повторной регистрации в каждом филиале - явная проблема
...И как любой заказчик, должны четко понимать что хотите...
Леонид. Спасибо за подробные разъяснения моих "заблуждений"
Сегодня одно, завтра другое, каждый день появляются костыли, которые нужно решать решать и еще раз решать.
Вот и думаю взяться за все.
"Выходит я аналитик, менеджер проекта, и TeamLeader."
1. Правильно ли я понимаю, что для проектов внедрения АС, ту часть которая про ПО можно описать, например по 19 ГОСТу (ну или формате функциональной спецификации), а все что относится к его внедрению как системы по 34?
Если это так, то возможно ли обосновать такой подход, опираясь на сам ГОСТ?
2. В общепринятой терминологии, в том числе при написании проектных документов, принято любой программный продукт называть системой,
тогда получается, что даже если ты продаешь заказчику ПО без внедрения, но в договоре обозвали это системой, то формально необходимо описывать ее с применением ГОСТ 34 (Если, в том же договоре, допустим будет прописано, что вся сопровождающая документация должна быть подготовлена на основе соответствующих ГОСТов)?
В программу и методику испытаний отлично запихивается. Но это уже стадия рабочего проектирования (для IT - написания кода). Из документов технического проекта для use-case наверно подойдёт "Описание автоматизируемых функций".
Попросим ответить экспертов. Одного мы уже знаем.
Спасибо всем, что помогаете разобраться в таком нелёгком деле, как работа по ГОСТ34
- Возможно ли в рамках разработки документации часть написать по ГОСТ34, а часть допустим по 19? Т.е. ТЗ пишем по 34, а руководство оператора по 19?
- Возможно ли оставить пакет документов без единого ТЗ, сразу оформить несколько ЧТЗ на каждую из подсистем?
- Как правильно отформатировать документ(ы)? Шрифт, поля, интервалы и тд.
- Какие из документов, описанных в 34201 являются СТРОГО обязательными?
- Насколько подробно необходимо описывать требования именно в ТЗ? И как понять, что необходимый уровень точности уже достигнут. (Здесь будем исходить из того, что подробные ФТ пишутся все-таки на стадии ТП, а в ТЗ пишутся требования верхнего уровня).
Могу добавить еще вопросы относительно ПМИ, если это пойдет в эту же тему.
Предлагаю в этой теме общими усилиями сформировать список вопросов по ГОСТ 34, а потом сделать из них FAQ.
