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

×


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

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


Сообщения - Григорий Печенкин

76
Вакансия актуальна!

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

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

Но зачем располагать всё на одной диаграмме? Отображение времени и работа радио/CD между собой никак не связаны и не влияют друг на друга. Конечно, если все состояния независимых элементов попытаться впихнуть в одну диаграмму, мы получим экспоненциальный рост её сложности (в пределе придётся перемножать количество состояний всех элементов).

Почему не изобразить две (или три, если так уж необходимо рисовать на диаграмме состояния "вкл/выкл")?

Каждая диаграмма рисуется с какой-то целью. Если это описание требований, то набор из нескольких диаграмм будет намного проще и понятнее. А в данном случае даже простое текстовое описание будет понятнее. Здесь на несчастные шесть состояний используется минимум шесть разных элементов языка. Такая визуализация бессмысленна.

78
Добрался до Фаулера.
Я не понимаю, зачем в одной диаграмме объединять абсолютно не связанные между собой сущности.

Цитировать
Если бы вы захотели представить это с помощью диаграммы непараллельных состояний, то получилась бы беспорядочная диаграмма при необходимости добавить состояния.

Но именно это в данном случае и получилось.

Цитировать
Разделение двух областей поведения на две диаграммы состояний делает ее значительно яснее.

Если бы это было так, то не было бы этой темы на форуме. Просто нечего было бы обсуждать.

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

80
Понравилось:
- "Управление требованиями, включая оценку трудоемкости реализации требований;" - да ладно? Аналитики оценивают трудозатраты программистов и "логистов" (в случае поставок железа)?

У нас аналитики тоже отвечают за оценку трудоёмкости. У них для этого есть своя методика и какие-то нормативы. Меня это тоже удивляет, но по факту оказывается, что у них это сравнительно неплохо получается.

81
Те, у кого нет опыта работы "в многозадачном режиме под постоянным давлением", ещё не хотят.
А те, у кого есть, уже не хотят.

82
Григорий вот даже выступал "Analyst Days 2015. Почему UML — плохой выбор для обучения аналитиков"
https://www.webursitet.ru/trainer/grigorii-pechenkin.html

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

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

Это вообще проблема многих подобных систем: они позволяют делают в базе данных практически что угодно, но остаются при этом инструментами аналитика. Других участников процесса в них загонять бессмысленно: у них свои погремушки. Поэтому и приходится интегрировать.

К тому же TFS, например, легко подключается мощный инструмент тестирования от Microsoft. Это "погремушка" тестировщиков, в которой они разрабатывают и выполняют тест-кейсы и планы тестирования. А благодаря интеграции с TFS эти тест-кейсы трассируются прямо на код. Так что если вы что-то поменяли в коде, система автоматически определит, какие тест-кейсы эти изменения затрагивают, и предложит их выполнить повторно.

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

83
Коллеги, если вам не нравится Cradle – аргументируйте.
Если вы считаете необходимым продвигать другой продукт – продвигайте на здоровье.

84
да, действительно, как я помню им приходится подтаскивать к EA вторую систему, в данном случае TFS, поскольку EA не поддерживает управление версиями, в отличие от Cradle, где есть встроенное управление версиями каждого отдельнго требования.

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

В узком смысле – это версии требований, трассировки и «статусы» требований. Аналитикам обычно понятна только эта часть «управления», но те «статусы», которые не относятся напрямую к разработке требований, – это для них только следы процессов, которые находятся вне зоны их контроля.

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

TFS – это инструмент командной работы. Его интеграция с инструментом разработки требований типа EA позволяет всем участникам процессов разработки получать требования в виде, пригодном для использования в их процессах, и автоматически фиксировать результаты их труда в тех самых «статусах».

85
Для всех / Re: Разработки
« : 15 Марта 2016, 22:31:48 »
Друзья!
Меня обрадовала российская статистика. За последние полгода фирмы, работающие в секторе IT-технологий увеличили доходы бюджета на 11%. 

11% от чего?

86
Не надо добавлять бессмысленные комментарии в тему, пожалуйста. Куда вы её "апаете"?

87
10. Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?

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


Коротко она пересказывается, например, здесь: http://foranalysts.blogspot.ru/2011/08/blog-post_17.html
Картинка в статье - из книги Вигерса "Разработка требований к программному обеспечению".

88
Я бы выбранное решение описал как отдельную сущность, связанную с требованием и решением.
Унарные связи - зло. Как правило это заплатка

Это если есть возможность создавать свою структуру БД. В нашем случае нужно эти сущности реализовывать на базе архитектуры имеющейся системы управления задачами, довольно жёсткой.

89
Сталкивались ли вы с такой проблемой и как бы вы обеспечивали согласованность жизненных циклов сущностей?

Сталкивался не раз.
Из свежего: в системе управления требованиями регистрируются (сюрприз!) сущности типа "требование". В этой же системе с каждым требованием может быть связан один или несколько вариантов решения (вторая сущность). На определённом этапе одно из решений должно быть выбрано, и дальше требование рассматривается с выбранным решением как единое целое.

Это был ответ на первую половину вопроса.
А вторую половину нужно уточнить: что значит "обспечить согласованность"? На каком уровне? На уровне понимания, описательной модели, модели реализации, структуры БД?

90
Да вроде нет у нас таких. Была тема, в которой собирались сформировать ЧАВО, да так и не собрались, помнится.

Однако у меня все ходы записаны. :) Вопросы есть, ответов только нет.