Использование UML в разработке программного обеспечения - PullRequest
0 голосов
/ 27 июля 2011

Мой вопрос касается разработчиков программного обеспечения, имеющих опыт работы с UML / UTP.

Введение В настоящее время мы находимся на начальной стадии нового проекта, где написана документация для оборудования со встроенным программным обеспечением. Я отвечаю за разработку GUI. В качестве отправной точки используется модель предшественника. Его графический интерфейс был представлен мне как первая информация с некоторыми запланированными изменениями.

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

Поскольку я считаю важным начать с тестовой документации, в паре с функциональной спецификацией, я думаю об использовании UML для описания функциональных частей. Для теста я думаю о тестировании на основе моделей и использовании UTP (UML Test Profile).

подробности: В нашей системе существует три типа пользователей (участников): техник электростанции, техник по вводу в эксплуатацию и системный эксперт. GUI в основном используется для 1. смотреть значения и изменять значения индекса 2. произвести ввод устройства в эксплуатацию (режим ввода в эксплуатацию) 3. установить новое программное обеспечение или выполнить обслуживание системы (режим эксперта)

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

МОЙ ВОПРОС: В таком проекте рекомендуется ли использовать UML / UTP и в какой степени? Можно ли рисовать для каждого простого доступа к меню диаграммы вариантов использования? Я не хочу быть пойманным лихорадкой UML (см. Смерть от лихорадки UML )

1 Ответ

0 голосов
/ 05 августа 2011

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

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

Если вы используете некоторую степень формальных процессов и / или управляемый набор инструментов, вам также необходимо принять это во внимание: как ваши модели вписываются в установленные процессы и как ваш инструмент вписывается в цепочку инструментов?

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...