256

Книги, статьи и ресурсы / Re: Иванова, Перерва.Путь аналитика. Практическое руководство IT-специалиста

« : 26 Мая 2015, 14:20:54 »

Вышло 2-е издание Пути аналитика, включая электронный вариант.

Что изменилось по сравнению с первым пока не понял, возможно просто доп.тираж: http://habrahabr.ru/company/piter/blog/258807/

Цена очень доступная, да ещё и скидку дают от хабра.

257

Конференции Семинары и Тренинги / Re: МСК — Тренинг «Практика разработки технического задания на ПО»

« : 25 Мая 2015, 13:04:13 »

Следущий тренинг пройдёт в сентябре в Москве c 17 по 19 сентября.

258

Для всех / Re: Какие из следующих компетенций есть у типичного консультанта по внедрению?

« : 25 Мая 2015, 12:09:17 »

Если пользоваться анекдотическим определением, то консультант — это тот, кто даёт точные и бесполезные ответы. Что и было продемонстрировано выше ^.

А автору, если действительно надо, я рекомендую поискать на hh.ru позиции консультантов по внедрению и проанализировать результаты выдачи.

259

Книги, статьи и ресурсы / Re: Моделирование требований пользователей в MS VisualStudio

« : 21 Мая 2015, 03:22:08 »

я повторяю свой вопрос

260

Книги, статьи и ресурсы / Re: Моделирование требований пользователей в MS VisualStudio

« : 20 Мая 2015, 18:41:49 »

Я в одном могу согласиться: это не диаграмма вариантов использования.

а что это?

261

Для всех / Re: UML - Диаграмма ассоциаций сценариев (?)

« : 14 Мая 2015, 16:59:56 »

Для начала учитесь писать утверждения в активном залоге.  КТО делает ЧТО. «Мама мыла раму», помните?

Не «требуется нарисовать», а есть конкретный X, который потребовал нарисовать:
Потенциальный работодатель или
Преподаватель или
Руководитель или
Разработчик теста.

ЕГО И СПРАШИВАЙТЕ.

Мы-то тут при чём? Нафига вы сюда вопросы пишете, а не автору «требований»?

262

Конференции Семинары и Тренинги / Re: Онлайн-курс «Практический анализ и моделирование на UML»

« : 12 Мая 2015, 13:51:46 »

Длительность курса увеличена до 8 занятий (32 часа).

Мы также ввели геоскидки за расстояние от Москвы.

263

Идеи и мозговой штурм / Re: Конференции для аналитиков

« : 10 Мая 2015, 21:42:26 »

Журнал «Системная инженерия»: http://systemsengineer.ru/

264

Обучение / Re: Требуется вводный пинок в моделирование на UML.

« : 07 Мая 2015, 01:48:39 »

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

265

Обучение / Re: Требуется вводный пинок в моделирование на UML.

« : 07 Мая 2015, 01:45:25 »

Андрей, ну почему, я вам такое в любом векторном редакторе нарисую, хоть в Google Draw.

В целом интересно, какого эффекта вы хотите добиться, отображая детали маппинга одной структуры данных на другую именно на диаграмме, а не в таблице?

Если прям совсем хочется рекомендую поискать по словам Data Mapping Diagram.

266

Управление Проектом / Re: TeamLeader + Manager Project для управления проектом, командой и графиком работы

« : 07 Мая 2015, 00:23:12 »

2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.

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

267

Управление Проектом / Re: TeamLeader + Manager Project для управления проектом, командой и графиком работы

« : 07 Мая 2015, 00:19:04 »

Смотрим дальше,

2.6.2. В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят:

1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;

2) временной регламент реализации каждой функции, задачи (или комплекса задач);
3) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;
4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

Как это маппировать на игру? Я не понимаю.

268

Управление Проектом / Re: TeamLeader + Manager Project для управления проектом, командой и графиком работы

« : 07 Мая 2015, 00:17:27 »

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

Вся смысловая риторика автоматизации как процесса замены участков человеческой деятельности автоматизированными и автоматическими функциями с сокращением затрат (времени, усилий и/или стоимости) совершенно не применима к игре. Игра наоборот стремится увеличить время и затраты в целом, проводимые в игре, что делает её более похожей на медиапродукцию.

Показатели назначения игры (количество игроков, увлекательность геймплея, доходность с одного участника и т.д.) не достигаются правильным определением состава функций, автоматизирующих деятельность и атрибутов её качества. Успех игры зависит не от правильного функционально-технического проектирования, а в большей степени от устройства «объекта автоматизации» — сценария игровой деятельности, который создаётся практически одновременно с самим приложением.

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

Единственное место, где может быть полезен ГОСТ 34 — при разработке бэкенда для системы, который будет представлять собой полноценную автоматизированную систему. И который опять же не нужен в полноценном объёме, если мы говорим про пилотирование новой игры, а не поддержку линейки игр, продуктового портфеля.

Давайте, в конце концов, посмотрим, что из основного состава ГОСТ 34.602 может хоть в принципе иметь какое-то отношение к мобильной игре:

2.6.1. В подразделе «Требования к системе в целом» указывают:

1. требования к структуре и функционированию системы; — в лучшем случае это геймплей + карта навигации + структура игрового мира. но как именно называние их таким образом поможет — не ясно
2. требования к численности и квалификации персонала системы и режиму его работы; — не применимо, у самой игры персонала нет
3. показатели назначения; — ну да, игра должна затягивать и приносить миллион долларов в месяц. но это не задание для программиста
4. требования к надежности; — хорошо описано в стандартах на софт
5. требования безопасности; — не применимо, если не считать ограничения на использование мельтешаших цветов и недопущение развития нервных расстройств, припадков эпилепсии и депривации сна. но чтобы это правильно сформулировать, нужно знать хоть что-то из эргономики, когнитивной психологии и социологии
6. требования к эргономике и технической эстетике; — даже ISO 9241/9126/25010 практически ничего не говорят о том, как задавать требования к графическому дизайну. я тоже не знаю
7. требования к транспортабельности для подвижных АС; — не применимо
8. требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; — не применимо
9. требования к защите информации от несанкционированного доступа; — любой продакт с минимальным опытом игры не забудет, что аккаунт должен быть с паролем
10. требования по сохранности информации при авариях; — важный момент для промышленной версии игры
11. требования к защите от влияния внешних воздействий; — не применимо или нужно подходить очень творчески
12. требования к патентной чистоте; — важный момент в ряде случаев
13. требования по стандартизации и унификации; — есть в стандарте на софт
дополнительные требования.

Итого, из 13 основных разделов требований:
5 — не применимы
2 — типовые категории из серии капитана очевидность (да, должны быть функции. да, должен быть пароль)
4 — требуют недюжинного кругозора за рамками программной инженерии чтобы быть использованными
2 — хорошие подсказки

269

Конференции Семинары и Тренинги / Re: Онлайн-курс «Практический анализ и моделирование на UML»

« : 06 Мая 2015, 12:11:56 »

Следующий курс пройдёт с 23 мая по 14 июня.

270

Управление Проектом / Re: TeamLeader + Manager Project для управления проектом, командой и графиком работы

« : 06 Мая 2015, 12:03:03 »

Денис, еще раз. Не "использование", а "знакомство". Ок, давайте через аналогии.

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

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

Что сказано в ГОСТ 34.602 про качество ПО и ограничения (о которых речь в приведённом вами кейсе)?

2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:
1) к независимости программных средств от используемых СВТ и операционной среды;
2) к качеству программных средств, а также к способам его обеспечения и контроля;

Всё.

Что сказано в
 «ГОСТ 28195-89. Оценка качества программных средств. Общие положения» (того же года, между прочим)?

Там приведены около 20 показателей качества ПО, включая, например:

4.3. Ресурсоемкость. Минимально необходимые вычислительные ресурсы и число обслуживающего персонала для эксплуатации ПС

Что сказано в «IEEE 830-1998. Методика составления спецификаций требований к программному обеспечению»?

5.2.1.6 Ограничения памяти
Этот подраздел должен определять любые применимые характеристики и ограничения первичной и вторичной памяти.

Что сказано в ГОСТ Р ИСО/МЭК 9126 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению»?
Там выделено 6 характеристик качества ПО и 30 подхарактеристик, включая:

4.4 Эффективность (Efficiences)
Набор атрибутов, относящихся к соотношению между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях.
…
А.2.4.2 Характер изменения ресурсов (Resource behavior)
Атрибуты программного обеспечения, относящиеся к объему используемых ресурсов и продолжительности такого использования при выполнении функции.

Что сказано в «ISO 25010 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models» ?
Там приведено уже 8 групп характеристик качества и около 50 конкретных атрибутов качества ПО, среди которых:

4.2.2
performance efficiency
performance relative to the amount of resources used under stated conditions
…
4.2.2.2
resource utilization
degree to which the amounts and types of resources used by a product or system, when performing its functions, meet requirements

Возвращаясь к вашему метафорическому/аллегорическому языку — зачем советовать людям документацию по лошади, если у них свинья и есть документация на свинью?

Можно очень долго рассуждать о том, что существуют требования "функциональные" и "нефункциональные", приводя при этом пару-тройку простеньких кейсов, но это не отразит всей палитры требований, в первую очередь - нефункциональных. ГОСТ же - отражает. И просто заставляет помнить о них.
ИМХО.

Он отражает НФТ к ИС. Причём это ГОСТ 89-го года. Стандарты на качество ПО и систем серии 250X0 — 2007-2011-го годов, причём, как я показал выше, дают около 50 атрибутов качества ПО против одного абстрактного «качества ПО» в ГОСТ 34.602.