4932
« : 17 Сентября 2007, 18:19:20 »
Здравствуйте, Алексей.
Спасибо за интерес к теме.
Действительно, старое руководство, кажется, дает больше свободы и студенту и руководителю. Лично я рекомендую (но не настаиваю) студентам использовать оформление записки по Вигерсу, по крайней мере, что касается анализа требований и формирование ТЗ. При этом студенты частенько используют то, что им дали в крусе Проектирование инфосистем (а их учать по Вендрову: Проектирование ПО для ЭИС).
Я совершенно не против того, что студент будет оформлять свою работу в рамках ГОСТов. Все равно в реальности эти записки далеки от правильного оформления документов. Но ведь наша задача не состоит в том, чтобы студент научился правильно оформлять документацию по ГОСТ или другим стандартам. Я думаю - главное умение показать свои знания в области проектирование ИС и ее компонентов. При этом один студент может показать высокие аналитические способности, другой отличные навыки программирования и т.д. Студент должен защищать свою квалификацию в выбранном направлении.
Почему вообще возникла потребность в каком-то изменении. В ходе ряда защит члены комиссии высказывали неудовольствие содержательной частью записки, в частности сложно было найти ТЗ, понять где собственно проектная часть и т.п. Кроме того, ряд членов комиссии, люди с солидным опытом жизни, высказывали недоумения структуре записке: что это за Аналитическая проектная и технологическая часть - мол таких элементов в реальной практики оформления ИТ-проектов нет. Потому предложена структура, которая формально отражает некоторые стадии жизненного цикла: ТехЗадание, Само проектирование и его реализация (Техпроект), Рабочая документация и Внедрение.
Насчет экономической части - сказать ничего не могу. Да она формальна. Это во многом зависит от консультанта по экономической части. Я уже давно рекомендую использовать для этого тот же MS Expert Project. Вообще лучше бы тут была не экономическая часть как таковая, а скажем формирование бюджета проекта с оценкой экономической эффективности, хотя последнее значительно натянуто и не ко всем работам подходит.
Анализируя дискуссию на форуме и личные переговоры с коллегами, можно попытаться предложить такую структуру.
Постановка задачи - краткое описание проблемы, объекта исследования
Обоснование выбора методологии проектирования - здесь студент выбирает некоторый подход к проектированию и оформлению документации, объясняет причины выбора, возможно перечисляет достоинства и недостатки методологии, инструментальную поддержку этапов жизненного цикла
Собственно проект - который уже будет содержать структуру выбранной методологии в том или ином объеме и вероятно будет содержать:
Концепцию
ТЗ
Архитектуру системы
Детальное проектирование
Вопросы конструирования
Результаты тестирования и соответствия заявленным требованиям (причем как мне кажется - это должен делать руководитель или рецензент)
Необходимую рабочую документацию, раскрывающие вопросы внедрения
что-то еще....
Причем последняя часть может сильно зависить от типа квалификационной работы и ее содержание может корректироваться
Просмотр сообщений
).