В целом это утверждение слишком смелое, поскольку в проекте обычно участвуют только двое, ну максимум трое человек:
заказчик, он же часто и руковдитель от вуза
руковдитель от вуза - скорее надсмотрщик и госприемщик
сам проектировщик - студент.

Сроки дипломной работы очень ограничены - максимум 4-5 месяцев.

Идеально, конечно, это летняя практика после 4 курса, курсовой проект в 1 семестре и дипломный проект во втором.

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

Итак, что я хочу сказать. Дипломный проет можно оценивать как краткосрочный, а следовательно часто одноитерационный и водопадный. Т.е. по определению такой проект разрабатывать итерационно сложно. Потому результаты дипломных проектов часто просто выбрасываются, так как к внедрению практически не подлежат.

Это присказка, не сказка, сказка будет впереди.

Мы уже тут дискутировали по поводу содержательно части дипломных проетов. Очевидно как минимум он может содержать техническое задание, проектное решение, описание программы.

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

Что содержится в ТЗ - более или менее понятно. Чаще всего это текст требований иногда какие-то контекстные модели. Я видел не так много ТЗ по ГОСТ, но в них не видел структурных схем, либо они были очень иллюстративные.

Далее идет собственно проект технический и рабочий. Разница между ними довольно тонкая, и часто их объединяют в технорабочий проект.

ТРП содержит решения, четкой корреляции с ТЗ нет, но обнаружить ее можно. Однако у меня всегда возникает вопрос, а где собственно описывается результат анализа требований, где описываются структурные схемы, процессные схемы бизнес-модели, где фиксируются и отображаются аналитические модели, логические модели, наконец модели реализации. Кажется очевидным что модель реализации может быть зафиксирована в технорабочем проекте (или же в рабочем?), а логическая модель в техническом? Тогда где место аналитической модели.

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

Вопрос: как следует разместить модели? и где? следует ли вообще рассматривать и публиковать аналитические модели и логические - может достаточно моделей реализации, или наоборот только логической?

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

Это очень сильное утверждение. В истории любой профессиональной деятельности есть примеры большого количество технических решений, которые были не востребованы, хотя были сделаны очень талантливо и содержали интересные идеи (которые потом растащили на части другие). Даже в истории отечественной ИТ отрасли. Любое предложенное решение должно быть кому-то полезно. Критерии пользы дают требования к решению. Чем больше эти требования от жизни, а не от профессинально-технологической специфики решения - тем меньше они стесняют творческую мысль создателя решения (в ГОСТе 34 на ТЗ про это прямо написали - не ограничивать требованиями возможные решения). Хорошо бы если бы можно было оиентировать специалистов на такие подходы уже с института.

Что содержится в ТЗ - более или менее понятно. Чаще всего это текст требований иногда какие-то контекстные модели. Я видел не так много ТЗ по ГОСТ, но в них не видел структурных схем, либо они были очень иллюстративные.

Далее идет собственно проект технический и рабочий. Разница между ними довольно тонкая, и часто их объединяют в технорабочий проект.

ТРП содержит решения, четкой корреляции с ТЗ нет, но обнаружить ее можно. Однако у меня всегда возникает вопрос, а где собственно описывается результат анализа требований, где описываются структурные схемы, процессные схемы бизнес-модели, где фиксируются и отображаются аналитические модели, логические модели, наконец модели реализации.

В ГОСТ 34 пространство для описания модели по уровням (видам моделей) очень ограничено. ГОСТ в значительной мере исходит из функциональной модели. Функция описывается входом и выходом, причем на уровне ТЗ функциональные требования формулируются к выходам функций, а требования к множеству входов фактически описывается в следующем разделе "информационное обеспечение". Уже на уровне ТРП пишется постановка задачи (есть там такой документ), там также упор на описание входов и выходов. Тут уже вход указывается для каждой задачи (функции - по ГОСТ задача это функция или часть функции). Поэтому ГОСТ лучше всего дружит с IDEF0, IDEF3 или DFD.

Кажется очевидным что модель реализации может быть зафиксирована в технорабочем проекте (или же в рабочем?), а логическая модель в техническом? Тогда где место аналитической модели.

Может быть можно рассматривать аналитическую модель как основу для описания требований? Тогда можно её поместить в ТЗ (ГОСТ 34) в раздел Характеристика объекта автоматизации.

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

Вопрос: как следует разместить модели? и где? следует ли вообще рассматривать и публиковать аналитические модели и логические - может достаточно моделей реализации, или наоборот только логической?

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

Это очень сильное утверждение.

Да согласен. Эту мысль я подчерпнул на просторах рунета и, в частности, где-то на http://authorit.ru или http://www.rugost.com. Пытался найти подтверждения - потерял.
Думаю имелось в виду та ситуация, когда разработчик сам придумывает идею и ее реализует. Соответсвенно ТЗ в том смысле, как документ соглашения между заказчиком и исполнителем не нужен. Но концепция с предполагаемыми формализованными требованиями, конечно, нужна.

Чем больше эти требования от жизни, а не от профессинально-технологической специфики решения - тем меньше они стесняют творческую мысль создателя решения (в ГОСТе 34 на ТЗ про это прямо написали - не ограничивать требованиями возможные решения). Хорошо бы если бы можно было оиентировать специалистов на такие подходы уже с института.

Да безусловно. Это описыватся во всех книгах по требованиям, это указано и в ГОСТах. К сожалению не могу утверждать, что это доносится до студентов.

В ГОСТ 34 пространство для описания модели по уровням (видам моделей) очень ограничено. Поэтому ГОСТ лучше всего дружит с IDEF0, IDEF3 или DFD.

Однако насколько я понимаю, ГОСТ - это не методология и никак не ограничивает использования разных подходов. Тем не менее из текста ГОСТа, из его семантики, действительно явно следует структурно-функциональный подход.
Что ж пусть так. Тогда интересно, какое место IDEF0, IDEF3 или DFD занимают именно в техническом задании или другом документе.

Диплом - есть уже конечный результат работы студента. Он безусловно не отражает динамики и логики выполнения реальной работы, даже если содержит план выполнения работ. Он фиксирует то, что получилось в конце деятельности. Потому диплом - очень упрощенная модель проекта. Динамику выполнения может видеть только руководитель дипломной работы, а студент может частично в презентации проекта озвучить ее. Однако ясно, что комиссия ГАК максимум что может ухватить - это наиболее значимые требования, увидеть - их реализацию. Мало интересно слушать или читать о драме развивающихся событий

Может быть можно рассматривать аналитическую модель как основу для описания требований? Тогда можно её поместить в ТЗ (ГОСТ 34) в раздел Характеристика объекта автоматизации.

Это интересно. Комментарии к этому разделу можно найти здесь.

Не очень понятно, что Вы имеете в виду под трассировкой спецификаций в код?

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

Реализация же будет выполнена в стиле событийно-ориентированного подхода, ООП. Скажем в Дельфи-проекте. Очевидно, тестирование и понимание того, чего хотел студент в проектном решении и что получил, явно затруднено либо вообще бесполезно.

Понятнее теперь ?

Если имеется в виду возможность установления соответствия между физическим и логическим уровнем, то их сильное различие скорее правило, чем исключение.

Да я согласен. Читая Лармана, можно понять почему. Однако нужно понимать различие уровней системы: некий уровень предметной области - он часто хорошо прослеживается от концептуального до физического и уровень приложения - то есть собственно реализация. У нас же в дипломных работах между моделями и их реализациями часто вообще ничего общего нет

Возможно, имеет смысл делать совсем простые системы для конкретных, очень частных задач (возможно, одноразовые ).

Конечно, я только за. Более того, в течение вот уже 6 лет я настойчиво призываю кафедру подумать над так называемым типовым проектом, и иметь банк различных тем.
Естественно это не исключает использование реальных задач, для конкретного закзчика. Я также постоянно пизываю студентов и их руковдителей ограничивать себя в амбициях на реализацию. Все же просто. Сделали анализ, выделили наиболее значимые требования и реализовали их в программе первой версии. Главное показать понимание и умение. Если задачи интересные и важные, можно продолжать их выполнения в следующие годы. Правда студенты - народ хитрющий.
В прошлом году сделала одна студентка задачу - типа рабочего места преподавателя. В целом работает система, однако неудобный интерфейс, некие функции не реализованы. Самое-то развивать дальше. Предложили другой студентке - закапризначала. Вот еще, мол, буду я в чужом коде разбираться, лучше я свое напишу с нуля.
В чем-то она права. Потому как в дипломе описана постановка и требования, достаточно грамотно описана схема БД и ее реализация, но вот модель приложения напрочь отсутствует. Понятно, что ковыряться в чужом коде без описания алгоритмов, общией схемы и деталей, мало интересно...

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

Реализация же будет выполнена в стиле событийно-ориентированного подхода, ООП. Скажем в Дельфи-проекте. Очевидно, тестирование и понимание того, чего хотел студент в проектном решении и что получил, явно затруднено либо вообще бесполезно.

Для объектного подхода - ВИ, UML для верхнеуровневых моделей. Делать реализацию объектного решения якобы на основе функциональной модели верхнего уровня (бизнес-уровень, аналитическая модель) дело неблагодарное. Лучше бы это действительно избегать...

Для объектного подхода - ВИ, UML для верхнеуровневых моделей. Делать реализацию объектного решения якобы на основе функциональной модели верхнего уровня (бизнес-уровень, аналитическая модель) дело неблагодарное. Лучше бы это действительно избегать...

К сожалению реальность такова, что объектную парадигму худо бедно преподают только в технологии объектного программирования. Про UML там не говорится не слово, хотя очень ценно было бы рассмотреть как использовать UML и ООП, т.е. как реализуются ассоциации, зависимости и т.п.

В прошлом году я пробил курс объектно-ориентированный анализ. Пытаюсь восполнить пробел.

Однако хотя в курсе проектирования ИС и читается UML, но явно не в том ракурсе. Практически читается не использование UML в проектировании, а просто нотацию и ее особенности.

Курсовые же работы по проектированию ИС построены на российском ГОСТ 34 и структурном подходе с ориентацией на DFD. Причем я читаю DFD на 3 курсе, практически за год до проектирования ИС. Что само по себе плохо, но при этом в курсе проектирования ИС при использовании DFD акценты на мой взгляд расставлены не верно.

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

Далее делается так называемая диаграмма нулевого уровня системных процессов, где просто к модели описанной выше добавляется например принтер .

Далее при защите курсовой делается упор на порядке оформления работы и оценивается фактически не реализация проекта в виде системы, хотя она и представляется, а то как оформлены вся работа. Соответсвие реализации требованиям, качество требования, выбранная архитектура и архитектурные решения вообще не прописаны и не озвучаны. Под архитектурой порой понимается, то что в ТЗ называется подсистемами системы.

Все это, конечно, печально.

Однако хотя в курсе проектирования ИС и читается UML, но явно не в том ракурсе. Практически читается не использование UML в проектировании, а просто нотацию и ее особенности.

А нужно ли специально читать "UML" или "UML в проектировании"? Как мне кажется, достаточно дать базовые знания за пол-пары в каком-нибудь вводном курсе, а потом просто неуклонно использовать его при изображении любой схемы или диаграммы.

Там, на самом деле, отдельно изучать-то нужно только "правильное" направление стрелок.

А нужно ли специально читать "UML" или "UML в проектировании"? Как мне кажется, достаточно дать базовые знания за пол-пары в каком-нибудь вводном курсе, а потом просто неуклонно использовать его при изображении любой схемы или диаграммы.

Там, на самом деле, отдельно изучать-то нужно только "правильное" направление стрелок.

Гриша, не могу согласится. Да, конечно, можно за пол пары быстренько пробежаться по всем диаграммках, вылить массу непонятной информации на головы бедных студентов. Все-таки нужна этапность. Как используется эта диаграмма и почему и т.д. Так что за пол пары можно сделать лишь беглый обзор. Но лекция - это не инструмент закачки информации, лекция должна быть практичной и демонстрировать принципы использования.

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

То что данная нотация должна потом использоваться для объясненеия подавляющего количества последующей информации - абсолютно согласен