Форум Сообщества Аналитиков
Общий раздел => Методологии => Тема начата: ekim от 29 Июня 2011, 21:39:58
-
Помогите, уважаемые аналитики.
вводная: есть диплом "разработка информационной системы бла-бла-бла". Функциональная модель предметной области и основные процессы в ней описаны с помощью UML (варианты использования + диаграмма состояний). БД описана в ERD. Разработана программа (представлен интерфейс).
проблема: рецензент пишет в замечании "Недостатками в работе являются: полное игнорирование стандартов, применяемых в сфере информационных технологий". Читайте между строк "а где ГОСТ 34?". Поясню: рецензент ярый сторонник ГОСТ 34 и только его признает, как правило привращая диплом в последовательное ТЭО, ТЗ, ТП.
вопрос: как грамотно объяснить в ответе на замечание, что есть и другие стандарты, и на какую методологию лучше напирать? RUP вроде слишком круто и сложно, а другие я знаю хуже.
-
Думаю, вам тут как раз пригодится основной навык аналитика: умение договориться с Заказчиком.
-
В том то и дело, что это же не заказчик. Рецензия пишется один раз и переделывать ее или диплом неразрешенно (по идее). Надо просто вразумительно ответить на замечания в ней.
Вот я и спрашиваю: что можете посоветовать сказать вместо "я использовал каскадную модель жизненного цикла". хотел сослаться на RUP, но размах не тот... Просто заказали автоматизировать некую деятельность - я ее автоматизировал.
-
ГОСТ 34 и им подобные не являются законоустановленными к обязательному использованию. Они носят рекомендательный характер. Тем не менее заказчик может потребовать оформления содержательной части по ГОСТ, кроме того, это может быть просто внутреннее требование вуза. Тогда никак не отвертеться.
Однако я совершенно не вижу никакого противоречия между использованием ГОСТ 34 и использования современных систем проектирования. Не помню, чтобы в ГОСТ где-то указывалось как правильно оформлять сведения о структуре базы данных, структуре классов, описание алгоритмов и сценариев реализации функциональности в объектном стиле и т.п.
В любом случае аргументом может быть - требование заказчика и факт, что заказчик готов оплачивать эту работу. Если заказчик требуя эту работу, никак не хочет оплачивать ее, то можно подумать о прекращении взаимоотношений с ним. Либо конструктивно договориться. Правда по опыту знаю с преподавателями договорится практически невозможно.
-
В основе ГОСТ 34 лежит функциональная модель системы (функция: вход-выход, задача - функция или часть функции - уши IDEF0 торчат отовсюду), а UML изначально задумывался как обобщение нотаций, возникших для описания объектноориентированных моделей. Использовать UML при написании конкретного документа ГОСТ можно, сложно выдержать идеологию декомпозиции системы по ВИ, согласованное представление системы на бизнес- и системном уровне по набору документов ГОСТ. Поэтому некоторые методические проблемы ощущаются при попытке привлечь UML для описания функциональных моделей.
Где-то встречал информацию, что авторы UML cознательно не стремились предлагать средства для описания моделей, которые можно описать IDEF0.
Хотя народ придумывает как всё-таки приспособить UML для описания декомпозиции функций через activities/actions.
-
Предполагалось, что единый комплекс стандартов и руководящих документов, относящихся к 34 системе, должен распространяться на автоматизированные системы различного назначения: АСНИ, САПР, ОАСУ, АСУП, АСУТП, АСУГПС, АСК, АСТПП, включая их интеграцию. Однако до сих пор часть стандартов 24, 14 и 23 системы продолжают действовать просто в силу того, что соответствующих им стандартов в серии 34 не существует. При этом на практике эти стандарты находят весьма ограниченное применение в силу их заметного морального устаревания.
и на какую методологию лучше напирать?
На ту что описана в дипломе, раз Вы это написали, то такое имеет место быть.
Да и вообще можно почитать по теме "игнорирование стандартов сфере информационных технологий"
Фраза формальная и на оценку в дипломе думаю не повлияет.
Ну сделал я по своему, работает.
Перельман тоже по своему думал :)
-
Всем большое спасибо за советы и помощь
-
ГОСТ 34.602 очень сильно помогает писать
Отличный формат. Позволяет мало думать о структуре и больше о содержании.