Форум Сообщества Аналитиков
Дисциплины => Обучение => Тема начата: Galogen от 06 Сентября 2007, 12:17:37
-
Новый учебный год с новыми идеями.
Вернее не идеями, а предложениями. От одного преподавателя поступило предложение обновить и уточнить тербования к содержанию квалификационных работ по специальности Информационные системы и технологии.
Он же произвел достаточно серьзеную работы и подготовил проект методических указаний. В основу указания преподаватель положил ГОСТ серии 34.
Структура методуказаний примерно такова.
1 Область применения
2 Основные положения
3 Структура пояснительной записки дипломного проекта
4 Структура основной части пояснительной записки дипломного проекта
5 Техническое задание
5.1 Перечень разделов технического задания
5.2 Назначение системы
5.3 Цели создания системы
5.4 Характеристика объектов автоматизации (и информатизации)
5.5 Требования к системе
5.6 Состав и содержание работ по созданию системы
5.7 Порядок контроля и приемки системы
5.8 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
6 Технический проект
6.1 Перечень разделов технического проекта
6.2 Пояснительная записка к техническому проекту
6.3 Схема функциональной структуры
6.4 Описание автоматизируемых функций
6.5 Программа и методика испытаний
6.6 Схема организационной структуры
6.7 Описание организационной структуры
6.8 Описание информационного обеспечения системы
6.9 Описание организации внутримашинной информационной базы
6.10 Решения по программному обеспечению
6.11 Решения по математическому обеспечению
7 Рабочая документация
7.1 Состав рабочей документации
7.2 Руководство пользователя
7.3 Описание технологического процесса обработки данных
8 Ввод в действие
Приложение А
При прочтении у меня создалось неодназначное впечатление.
С одной стороны указания следуют основным положениям ГОСТов.
-ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
-ГОСТ 34.601-90 Информационная технология. Автоматизированные системы. Стадии создания;
-ГОСТ 34.602-89 Информационная технология. Техническое задание на создание автоматизированной системы;
-ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем;
-РД 50-34.698-90 Информационная технология. Автоматизированные системы. Требования к содержанию документов;
- ГОСТ 19.701-90 (ИСО 5807-85) Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения
Но с другой стороны они слишком формализованы.
Указания совершенно не дают свободы творчества студенту, лишают его возможности проводить исследование по выбранной теме. Поскольку, если следовать указаниям (а они очень объемные),то простое оформление всего указанного, на мой взгляд, займет как раз все время от преддипломной практики до предзащиты.
Интересно какие указания на подобную тему используются в других вузах?
Какие соображения у сообщества и посетителей форума по виду указаний и содержанию дипломных проектов?
Могли бы вы поделиться (прицепить) методические указания на дипломное проектирование, чтобы посмотреть и сравнить?
Общие мои замечание: используется ГОСТ для оформления алгоритмов и графической части совершенно не учитывающий факт наличие других нотаций и подходов, существование ОО парадигмы, UML, методологий разработки ПО и систем.
-
Тема как я понимаю интереса не вызывает. Это понятно.
Хорошо давайте поставим вопрос немного по другому. Очевидно, что работа квалификационная и соотвественно должна отражать квалификацию студента. Ясно, что правильно оформленная документация отражает лишь факт, что студент способен работать техническим писателем, грамотен, аккуратен и педантичен.
Насколько я понимаю среди разработчиков ПО и ИС таких не много. Я имею в виду педантичных и умеющих оформлять документацию.
Так или иначе, выбор в качестве внутреннего стандарта ГОСТов нормальное решение. Однако существующие ГОСТы сильно конфликтуют с новыми практиками разработки.
Вопрос: существует ли трассировка между российскими ГОСТами и документами и артефактами разлияных методологий разработки ПО?
Если да, то каким образом все это реализуется на практике? Насколько я могу знать, ИТ-компания может использовать некую технологию разработки, но техдокументацию и проектную документация оформляет по росГОСТам.
-
Если да, то каким образом все это реализуется на практике? Насколько я могу знать, ИТ-компания может использовать некую технологию разработки, но техдокументацию и проектную документация оформляет по росГОСТам.
Насколько я знаю, в первом приближении - только если заказчик предъявил такое требование. Это чаще всего означает, что заказчик представляет государственное предприятие или учреждение, а у исполнителя достаточно ресурсов, чтобы это требование выполнить.
Лично мне приходилось сталкиваться с документацией, оформленной по ГОСТам, только в крупных гос. учреждениях, и то это было достаточно давно.
-
Между RUP'ом и ГОСТами вроде были попытки сделать трассировку, но чаще всего это внутреннее ноу-хау компании. Т.е. я слышала про такой вариант: хочет клиент по RUP - сделаем по RUP, хочет по ГОСТу - выведем по ГОСТу, Настраиваем Sodу на нужный вариант и генерим. Но в живую такого чуда не видела. Про трассировки между ГОСТами и остальными методологиями даже не слышала.
Мои соображения по поводу первого поста: Эд, у меня ничего не осталось из методуказаний, но в наше время отдельно ТЗ и технический проект не делали. А на диплом по специальности 2201 Вычислительные машины, комплексы, системы и сети в 1999 году сдавались работы, в которых были экономическая глава (расчет себестоимости по-моему), техника безопасности (совершенно отдельная тема, взятая с потолка и выданная студенту на разжевывание в главе), обзор литературы и анализ прототипов, ну и основная часть, где описывалась структура базы данных, структура разрабатываемого программного комплекса, используемый матаппарат. Программы-методики испытаний, орг.структуры, организации внедрения и приемки не было. Так же не входило руководство пользователя. Т.о. структура по сравнению с этим набором была значительно уже. А от ГОСТов требовалось в основном оформление по ЕСПД: милиметраж рамки основной надписи на каждом листе, отступы при нумерации заголовков и все такое прочее.
-
Насколько я знаю, в первом приближении - только если заказчик предъявил такое требование. Это чаще всего означает, что заказчик представляет государственное предприятие или учреждение, а у исполнителя достаточно ресурсов, чтобы это требование выполнить.
Лично мне приходилось сталкиваться с документацией, оформленной по ГОСТам, только в крупных гос. учреждениях, и то это было достаточно давно.
Очень интересно. Ибо автор МУ (методуказаний по кваработе) в качестве аргумента приводит следующий текст:
2. Этими стандартами пользуются многие ныне действующие российские организации и предприятия, например:
а) московский НИИ "Восход", директор этого НИИ является председателем комитета МТК 22 Росстандарт по ИТ. Я с ним связывался, могу еще раз связаться, уточнить;
б) ОАО Автокран (частично);
в) ОАО «Рыбинские моторы» (частично);
г) Уральский электромеханический завод (Атомпром);
д)Новосибирский химаппарат (Атомпром);
е) Московский завод «Молния» (Атомпром ) и др.
3. Надо осознавать, что использование всех стандартов (кроме перечня, стандартов утвержденных правительством – стандарты по ИТ в этот перечень не входят) является добровольным. В нашей власти их игнорировать. Многие предприятия и организации так и делают.
очень интересен факт перечисления предприятий никаким боком к ИТ-индустрии не принадлежащим.
Интресено бы узнать статистику использования ГОСТов. Кто-то может высказаться по этому поводу?
-
Ира, к сожалению твой ответ ничего не прояснил.
Возможно это лишь говорит, что реально росГОСТами действительно мало кто пользуется. Вопрос а зачем такие ГОСТы нужны, а что тогда брать за основу? Международные?
PS Кстати надо тебе дать каст почитать - как писать письма правильно :-) Или отправить к Глебу Архангельскому :-)
-
Ира, к сожалению твой ответ ничего не прояснил.
Видимо, плохо поняла твой вопрос, болею.
Возможно это лишь говорит, что реально росГОСТами действительно мало кто пользуется. Вопрос а зачем такие ГОСТы нужны, а что тогда брать за основу? Международные?
Не знаю, компания-разработчик обычно подстраивается под заказчика. Известные мне примеры: для казначейства писали документацию по ГОСТам, для банков - по-моему мы ни разу не писали по ГОСТам ни ТЗ, ни пользовательскую документацию.
Я в работе над пользовательской документацией использовала даже не ГОСТы, а книги Липаева по ГОСТам и иностранным стандартом для того, чтобы проверить не упустила ли чего важного. Но на формат и структуру не заморачивалась. Т.е. знакома только с отношением к ГОСТу как к "Best Practices"
PS Кстати надо тебе дать каст почитать - как писать письма правильно :-) Или отправить к Глебу Архангельскому :-)
Ссылку в студию! Люблю учиться новому.
-
Здесь может быть множество факторов, которые следует учесть.
Возможно, этот ВУЗ готовит специалистов по информационным системам определённого профиля - для отрасли, в которой преимущественно используются ГОСТы.
Возможно, большинство выпускников факультета идут работать на крупные и гос. предприятия.
Возможно, у ВУЗа даже есть соглашения с какими-то предприятиями о трудоустройстве выпускников.
Возможно также, что сам преподаватель не особо знаком с "другими нотациями и подходами" (в исходном посте об этом ничего не сказано, поэтому я могу позволить себе такое чисто теоретическое предположение ;) )
И т. д.
Могу сказать о себе (не сочтите за нескромность, но с некоторых пор я ссылаюсь преимущественно на личный опыт, потому что другого, как оказалось, нет :) ).
Моя специальность по диплому - Математическое обеспечение автоматизированных систем управления. Вроде бы, красиво и всё ещё актуально. :)
Но ВУЗ - военное авиационное инженерное училище. Соответственно, по выпуску я попал в лётно-испытательный центр, и общался в основном с представителями монстрообразных предприятияй и институтов авиационной промышленности. Где всё делалось (и наверняка до сих пор делается) строго по ГОСТ. Соответственно, что такое ТЗ, эскизный проект, технический проект, макет, различные виды испытаний - всё это мне пришлось изучать на месте, в процессе испытательной работы. Более того, без этих знаний моя деятельность вообще не имела бы смысла.
Если бы мне в училище пришлось выполнить подобную квалификационную работу - этот опыт мне бы тогда очень пригодился!
Другое дело, если выпускники из ВУЗа оправляются в свободное плавание и в конечном итоге оседают в разных бизнес-структурах. Здесь, пожалуй, современные методики будут востребованы намного больше, чем ГОСТы. Их, скорее, нужно ориентировать на ISO и зарубежные стандарты. Соответственно, и квалификация требуется несколько другая.
-
Возможно, этот ВУЗ готовит специалистов по информационным системам определённого профиля - для отрасли, в которой преимущественно используются ГОСТы.
Поскольку мы обсуждаем реальную ситуацию, т.е. Вуз, где я работаю, то этого нет.
Возможно, большинство выпускников факультета идут работать на крупные и гос. предприятия.
Крайне незначительно для нашей специальности, а о химиках мы ничего не говорим ...
Возможно, у ВУЗа даже есть соглашения с какими-то предприятиями о трудоустройстве выпускников.
В наешм случае опять отриццательный ответ. Но каждый год у нас проходят ярмарки вакансий. Несколько человек таким образом распределились...
Возможно также, что сам преподаватель не особо знаком с "другими нотациями и подходами" (в исходном посте об этом ничего не сказано, поэтому я могу позволить себе такое чисто теоретическое предположение ;) )
Умолчим из скромности, ибо обсуждать отсутствующего не очень скромно :)
И т. д.
А нет никакого т.д. Все в нашей власти. В данном случае я вижу конфлитк навыков, студент скажем активно изучает некий SCRUM-процесс, а его требуют как стандарт оформить работу по ГОСТу, мне кажется у него крыша поедет. У меня поехала. Я сразу представил, что все время подготовки к защите, буду оформлять свою работу по ГОСТ - стало просто дурно...
Другое дело, если выпускники из ВУЗа оправляются в свободное плавание и в конечном итоге оседают в разных бизнес-структурах. Здесь, пожалуй, современные методики будут востребованы намного больше, чем ГОСТы. Их, скорее, нужно ориентировать на ISO и зарубежные стандарты. Соответственно, и квалификация требуется несколько другая.
Да последнее наиболее вероятно.
-
Ира, к сожалению твой ответ ничего не прояснил.
Возможно это лишь говорит, что реально росГОСТами действительно мало кто пользуется. Вопрос а зачем такие ГОСТы нужны, а что тогда брать за основу? Международные?
ИМХО большая часть денег, которая осваивается проектным образом (т.е. сначала проектируем, описываем, потом делаем в соовтетствии с описанным) делается для (полу)госудрарственных заказчиков. И там, как писал greesha, нужно работать по ГОСТ. Так что ГОСТ очень даже востребован. Минус - он заточен под функциональную модель, а разработчики объектных моделей часто обходятся без неё. И бывает проблема в какой из требуемых по договору документов удобнее воткнуть диаграмму классов.
Не предусмотрено в нем и многоуровневых моделей (ну не все 7 уровней открытых систем, то хотя бы как, не нарушая букву ГОСТ, описать физический и логический уровень бывает проблематично).
Но народ выкручивается :). Так что ГОСТ пока рано списывать со счетов, важно только оговорить для каких соверменных подходов он плохо применим (и даже - какие современные подходы плохо дружат с функциональным представлением о системе :)).
-
Так что ГОСТ пока рано списывать со счетов, важно только оговорить для каких соверменных подходов он плохо применим (и даже - какие современные подходы плохо дружат с функциональным представлением о системе :)).
Нет, Shur, я не за то, чтобы его выкидывать, а зато, чтобы его грамотно использовать. Т.е. в МУ как и следует обыграть ситуация с современными подходами, хотя бы разделить структурный подход и объектный и показать, что в каком случае применять из ГОСТОв и как.
-
Мои 5 копеек по ГОСТам.
Во первых, надо выяснить по каким конкретно ГОСТам. Если речь идет о назначении кодов документам, рамочках и штампах - это вообще не проблема.
Серёжа, я кажется привел список используемых ГОСТОв
Просто я думаю у преподавателей у самих нет четкого представления об использовании ГОСТа, не говоря уж о гибкости. Потому надо ко всему этому подбираться постепенно. Но пока не совсем понимаю как :(
-
Нет, Shur, я не за то, чтобы его выкидывать, а зато, чтобы его грамотно использовать. Т.е. в МУ как и следует обыграть ситуация с современными подходами, хотя бы разделить структурный подход и объектный и показать, что в каком случае применять из ГОСТОв и как.
Эд, по-моему это сюжет для книги. Вот есть книга, которая описывает использование гибкого моделирования в agile подходах и в RUPе. А ты хочешь получить сюжет книги, которая описывает использование ГОСТов в оформлении документации в agile проектах и в RUP-проектах. Такого слоника быстро нам не осилить!
-
Эд, по-моему это сюжет для книги. Вот есть книга, которая описывает использование гибкого моделирования в agile подходах и в RUPе. А ты хочешь получить сюжет книги, которая описывает использование ГОСТов в оформлении документации в agile проектах и в RUP-проектах. Такого слоника быстро нам не осилить!
Ага, есть ещё книга, которая описывает использование RUP в виртуальной команде, разрабатывающей микроскопическую программу учёта времени, ежедневно затрачиваемого программистами. Но чтобы такое написать, надо быть сотрудником Rational. ;) Других вариантов в реальной жизни я как-то не представляю.
-
Нет, братцы и сестры, этак мы уйдем в такие дали, что не очень-то и дойти.
Понимаете нужен документ соглашение
- для преподавателей-руководителей, чтобы знать, а что там должно быть вообще в проекте;
- для студентов - аналогично + точно знать какие части в каком объеме и с каким примерно содержанием описывать
- комиссии, ну чтобы оценивать работы по одним критериям. Хотя мне кажется чаще всего критерий один - реализация + грамотный рассказ о том, что нужно сделать и как делалось с иллюстрациями
Просто прочитав предложенную рукопись, я ведь сразу стал прокручивать куда чего вставить, если скажем будем мы с ребятами RUPить по-черному, Agileилить по-крупному, SCRUMничать в тихоря. Получается, что в выгодной ситуации окажется тот, кто сразу взялся за структурный подход и не парился. Получается описание проекта само по себе, а как делал - ну кого это больно волнует. И чему же мы таки научили? И к чему мы призываем народ?
Рыба ищет где глубже, человек где меньше всего надо делать. Вот чего я сильно опасаюсь.
В результате я все-таки с ребятами оформлю как нам лучше для того, чтобы представить свой проект. А комиссия раз и снизит ему за оформление - мол не стандартно у вас мил человек!
-
Нет, Shur, я не за то, чтобы его выкидывать, а зато, чтобы его грамотно использовать. Т.е. в МУ как и следует обыграть ситуация с современными подходами, хотя бы разделить структурный подход и объектный и показать, что в каком случае применять из ГОСТОв и как.
1. По жизни не все документы из ГОСТ используются в проекте. Поэтому пункты структуры методуказаний можно предложить студентам использовать в качестве каталога, из которого они должны выбрать те, которые, как они считают, необходимы для их конкретной работы. И в качестве главного ограничения свободы выбора студентов можно поставить условие, что выбранные документы должны покрывать все стадии проекта (ГОСТ 34.601-90), хотя, возможно, и с рзной степенью полноты.
2. ИМХО неверно требовать от дипломника чтобы он одинаково полно писал и ТЗ и тех. проект. Требует раздвоения личности - представлять себя то Заказчиком (когда пишешь ТЗ), то исполнителем (когда техпроект). По жизни очень часто бывает, что Исполнитель пишет и ТЗ и техпроект потом, но это если ТЗ - простая формальность. А написать в даже в этом случае хорошее ТЗ без искушения проваливания в обсуждение деталей разработки (уровня техпроекта) - для разработчиков сущее мучение. Проблемы, как правило, вылезают на уровне описания программы и методики испытаний - Заказчик стремится испытывать систему как черный ящик, а границы этого черного ящика как раз задаются и должны выдерживаться при написании ТЗ (с чем разработчики, пишущие ТЗ, часто не справляются). Поэтому ИМХО полезно, когда за написания ТЗ и программы испытаний отвечают одни люди, а за техпроект- другие. Может быть возможно рзрешить дипломникам акцентировать свои работы с точки зрения роли, в которой они себя видят? Наверняка большая часть будет писать техпроекты, а задачу написания диплома с акцентом на ТЗ можно рекомендовать тем, кто стремится в аналитики :).
-
В результате я все-таки с ребятами оформлю как нам лучше для того, чтобы представить свой проект. А комиссия раз и снизит ему за оформление - мол не стандартно у вас мил человек!
Наверное, методуказания должны требовать, чтобы дипломник декларировал явно в какой методологии он выполнил работу и комиссия должна будет оценивать работу на соответствие заявленной методологии (как по оформлению, так и по сути). Описанный в первом посте список можно оставить как рекомендацию тем, кто выбрал ГОСТ, которая должна облегчить работу студентам, не более того.
Издавать нормативные документы от кафедры, которые фактически будут задавать свою трактовку (версию?) методолгий представляется нескромным :).
-
Издавать нормативные документы от кафедры, которые фактически будут задавать свою трактовку (версию?) методолгий представляется нескромным :).
Нет нет, мы об этом и не думаем. Надеюсь, дело будет сделано. В конце концов останемся со старым вариантом :)
Кстати дискуссия позволила посмотреть на все с разных сторон.
-
Вопрос: существует ли трассировка между российскими ГОСТами и документами и артефактами разлияных методологий разработки ПО?
Юрий Булуй проводил подобную работу. Я в сети встречал его презентацию к докладу на какой-то конференции. Не сохранил. А теперь найти не могу :(. Юрий, может быть, выложите ее нам на растерзание.
Работа называлась "классификация требований".
-
Как всегда мне очень нравится бежать впереди паровоза.
Внимательно почитал презентацию Юры, которая у меня уже если не год лежит.
Кроме того, отличный анализ связи ГОСТ с другими видами документов и методологиями сделан в курсе "Анализ требований (http://www.intuit.ru/department/itmngt/analisis/)".
Однако, это не решает пока задачи, а что должно быть в рекомендациях и какими они должны быть.
Для развития мысли все-таки приведу текст содержания старых методуказаний
вот они:
АННОТАЦИЯ (1 стр.)
ВВЕДЕНИЕ (2 - 3 стр.)
1. АНАЛИТИЧЕСКАЯ ЧАСТЬ (10 - 15 стр.)
2. ПРОЕКТНАЯ ЧАСТЬ (20 - 25 стр.)
3. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ (20 - 25 стр.)
4 ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ (6 - 10 стр.)
ЗАКЛЮЧЕНИЕ (1 - 2 стр.)
Ну и самое примерное содержание
Аннотация. Текст аннотации (реферата) представляет собой краткое изложение всей работы с основными сведениями и выводами. В ней целе-сообразно кратко охарактеризовать: цель работы, объект исследования или разработки; основные методы исследования, анализа и проектирования; полученные результаты их область применения и новизну; основные кон-структивные, технологические и технико-эксплуатационные характери-стики; рекомендации по внедрению (результаты внедрения); общую и эко-номическую эффективность. В аннотации следует привести сведения об объеме пояснительной записки, количестве иллюстраций, таблиц, количе-ство использованных литературных источников.
Введение является частью проекта, в которой следует четко отразить цели и задачи работы, объект и технические средства, на которые он ори-ентирован. Целями работы могут быть: разработка информационной сис-темы в условиях применения новых технических средств сбора, передачи, обработки и выдачи информации; совершенствование существующей ин-формационной системы с решением комплекса ранее не решавшихся задач управления или решавшихся без использования информационных техно-логий. Необходимо также перечислить вопросы, которые предлагается рассмотреть в работе и вопросы, которые предполагается решить практи-чески, сформулировать новизну и актуальность разработки.
Аналитическая часть должна содержать описание объекта проек-тирования, его основные характеристики и комплекс решаемых задач. Здесь следует обосновать необходимость внедрения информационных тех-нологий, проанализировать возможные направления информатизации, рас-смотреть альтернативные варианты и выбрать оптимальный. В необходи-мых случаях в данном разделе может быть проведена идентификация объ-екта на основе существующих математических моделей.
Проектная часть должна включать в себя постановку задач инфор-мационного и программного обеспечения объекта проектирования. Здесь должны быть представлены информационные и логические модели объек-тов, характеристики циркулирующей информации, алгоритмы, блок-схемы и исходные тексты разрабатываемых программных модулей, программную реализацию комплекса задач (в том числе и с использованием существую-щих пакетов прикладных программ).
Технологическая часть должна содержать рекомендации по ис-пользованию конкретных технических средств и системного программного обеспечения. Здесь же должны быть приведены необходимые сопроводи-тельные материалы (руководства), описаны мероприятия по защите ин-формации и обеспечению достоверности ее преобразования.
Экономическая часть проекта должна быть посвящена выбору и обоснованию методики расчета экономической эффективности проекта и расчету соответствующих показателей. Подробное содержание данной части дипломного проекта определяется консультантом по экономической части.
В заключении рекомендуется сделать выводы по дипломной работе, указать направления дальнейшего совершенствования разработанной сис-темы и возможные пути ее внедрения на других предприятиях.
Далее по тексту идет разъяснение пунктов, но без навязывания каких-либо нотаций, ГОСТов и т.п. Т.е. просто описывается общий круг вопросов, на которые следует ответить при оформлении записки. В частности раскрывают отдельные тематики: создания АРМ, БД, модернизация, конфигурирование и т.п.
В качестве примера приведу тематику для АРМ:
4.1. Тематика, связанная с разработкой информационного и про-граммного обеспечения информационных систем и АРМ
Примерный перечень материалов основной части дипломного проек-та.
1. Аналитическая часть
Разработка основных требований к информационному и программному обеспечению
Обоснование необходимости разработки информационного и про-граммного обеспечения
Анализ возможных вариантов информационного и программного обес-печения
Обоснование выбора инструментальных средств, систем программиро-вания, пакетов прикладных программ, СУБД
2. Проектная часть
Разработка системы показателей и реквизитов и системы классифика-ции информации.
Разработка системы кодирования информации.
Унификация форм документов и разработка системы документооборо-та.
Разработка основных принципов организации базы данных.
Разработка концептуальной и логической схем базы данных.
Разработка структуры информационных массивов.
Обоснование и выбор стандартных методов, алгоритмов и программ поиска информации, внесения в нее изменений, сжатия информации, уменьшения времени приема и выдачи хранимой информации
Обоснование необходимости разработки нестандартных алгоритмов и программ.
Разработка нестандартных алгоритмов и программ.
3. Технологическая часть
Обоснование и выбор комплекса технических средств
Обоснование и выбор машинных носителей
Разработка (выбор) программных средств обеспечения достоверности преобразования информации и сохранности информационных массивов.
Привязка разработанного комплекса программ и информационных мас-сивов к комплексу технических средств
Описание основных режимов функционирования системы
Разработка сопроводительной документации.
В свете вышеизложенного приведу цитату коллеги
"в общем, у меня родилось такое же предложение, как в конце у Shur. по-моему, студенту нужно предложить создать пакет документов в соответствии с той методологией, которую он выберет. как ты знаешь, мнение, что agile-методики не используют документы, является заблуждением.
другое дело, что если основываться на ГОСТ, то только письменные документы дают какое-то представление о проекте и процессе его реализации. а для гибких методик надо потребовать еще какие-то артефакты - те же карточки историй заказчика
...а почему МУ должны задавать, фактически, шаблон выполнения работы? пусть они задают перечень ВОПРОСОВ, на которые представленные артефакты должны отвечать
...наличие этих частей ничему не противоречит. просто надо сформулировать список вопросов, на которые должны отвечать представленные в части документы. например, аналитическая часть - описание бизнес-процессов и плана их модернизации. в какой нотации и по какой методике - неважно
и, конечно, надо включить во введение требование обоснования выбора методики
...меня всегда убивали методички, в которых все разжевано. это обман студента, на самом деле - в жизни так не бывает, всегда надо делать какой-то выбор и что-то адаптировать. поэтому если мы хотим приблизить квал. работу к жизни, то надо ставить вопросы и требования, а не предлагать план ответа"
Таким образом, идея такая - а имеет ли смыл что-то менять, может только содержательную часть разделов более четко?
-
Имхо, не надо особо ничего менять, все уже и так дешево, надежно и практично. Может, действительно, четкости добавить, и убедиться, что терминология понятна студентам. А то бывает так, что лекции дают в одной терминологии, а МУ в другой.
-
1. Вообще, тема,затронутая Эдуардом, для меня тоже достаточно актуальна. Года через 2 у нас созреет первый выпуск и прийдется резко соображать методичку для дипломной работы.
На мой взгляд старая структура диплома предоставляет больше свободы для творчества. Если взять и привязатся к ГОСТу то тут есть два варианта либо все делать по нему, либо брать только некоторые виды документов. К тому же по опыту скажу,что ГОСТ как правило перегружен всякими безсодежательными документами порою не несущими никакого смысла. Мне доводилось один раз оформлять документацию на ПО по ГОСТу для одного оборонного предприятия. В принципе работа не сложная если есть шаблон но жутко рутинная :(. Возникает вопрос: а нужно ли это студенту? Ведь если он будет работать на таких предприятиях,где требуют оформлять по ГОСТ то этому его и так научат. Таких знатоков- старичков сейчас хоть отбавляй, а вот людей реально что-либо делающих очень мало, особенно в оборонке, куда зачастую идет молодой специалист, чтобы откосить от армии.
Поэтому привязываться к ГОСТ все равно что подрезать птице крылья. К тому же на каждом предприятии и даже в каждой фирме выработался или вырабатывается свой набор документов. Где по госту а где просто по наитию
2. А теперь по структуре. Можно оставить старую структуру но с изменениями. Я думаю пора выкинуть всякие экономики и БЖД из диплома- все это давно превратилось в формальность. Мы, например, на кафедре так и сделали. Я считаю лучше всего делать привязку к Жизненному циклу ПО. Это то что подтверждено и временем и практикой. Сюда легко можно увязать и RUP и все остальное. А вот какой ЖЦ выбрать -должен решать студент с руководителем. Здесь все зависит от уровня знаний и того и другого.
3. И наконец диплом - это все-таки квалификационная работа и должна удовлетворять определенным формальным требованиям. К тому же в комиссию порой входят люди не очень хорошо знакомые с современными методиками проектирования ПО. Для них RUP- это ново и не совсем непонятно, а то что непонятно вызывает раздражение. Нужно это учитывать.
Короче говоря нужно искать разумный компромис между ГОСТ, старой методикой и современными методами. Брать из них лучшее и использовать.
Вот мои соображения :)
-
Здравствуйте, Алексей.
Спасибо за интерес к теме.
Действительно, старое руководство, кажется, дает больше свободы и студенту и руководителю. Лично я рекомендую (но не настаиваю) студентам использовать оформление записки по Вигерсу, по крайней мере, что касается анализа требований и формирование ТЗ. При этом студенты частенько используют то, что им дали в крусе Проектирование инфосистем (а их учать по Вендрову: Проектирование ПО для ЭИС).
Я совершенно не против того, что студент будет оформлять свою работу в рамках ГОСТов. Все равно в реальности эти записки далеки от правильного оформления документов. Но ведь наша задача не состоит в том, чтобы студент научился правильно оформлять документацию по ГОСТ или другим стандартам. Я думаю - главное умение показать свои знания в области проектирование ИС и ее компонентов. При этом один студент может показать высокие аналитические способности, другой отличные навыки программирования и т.д. Студент должен защищать свою квалификацию в выбранном направлении.
Почему вообще возникла потребность в каком-то изменении. В ходе ряда защит члены комиссии высказывали неудовольствие содержательной частью записки, в частности сложно было найти ТЗ, понять где собственно проектная часть и т.п. Кроме того, ряд членов комиссии, люди с солидным опытом жизни, высказывали недоумения структуре записке: что это за Аналитическая проектная и технологическая часть - мол таких элементов в реальной практики оформления ИТ-проектов нет. Потому предложена структура, которая формально отражает некоторые стадии жизненного цикла: ТехЗадание, Само проектирование и его реализация (Техпроект), Рабочая документация и Внедрение.
Насчет экономической части - сказать ничего не могу. Да она формальна. Это во многом зависит от консультанта по экономической части. Я уже давно рекомендую использовать для этого тот же MS Expert Project. Вообще лучше бы тут была не экономическая часть как таковая, а скажем формирование бюджета проекта с оценкой экономической эффективности, хотя последнее значительно натянуто и не ко всем работам подходит.
Анализируя дискуссию на форуме и личные переговоры с коллегами, можно попытаться предложить такую структуру.
Постановка задачи - краткое описание проблемы, объекта исследования
Обоснование выбора методологии проектирования - здесь студент выбирает некоторый подход к проектированию и оформлению документации, объясняет причины выбора, возможно перечисляет достоинства и недостатки методологии, инструментальную поддержку этапов жизненного цикла
Собственно проект - который уже будет содержать структуру выбранной методологии в том или ином объеме и вероятно будет содержать:
Концепцию
ТЗ
Архитектуру системы
Детальное проектирование
Вопросы конструирования
Результаты тестирования и соответствия заявленным требованиям (причем как мне кажется - это должен делать руководитель или рецензент)
Необходимую рабочую документацию, раскрывающие вопросы внедрения
что-то еще....
Причем последняя часть может сильно зависить от типа квалификационной работы и ее содержание может корректироваться
-
Собственно проект - который уже будет содержать структуру выбранной методологии в том или ином объеме и вероятно будет содержать:
Концепцию...
Имеется ввиду концепция методологии, например, той же RUP или концепция разрабатываемой ИС?
ТЗ
Могу предложить такую структуру ТЗ (близко к ГОСТу, выбросил некоторые пункты )
1. НАИМЕНОВАНИЕ
1.1. Наименование - .
1.2. Заказчик –
1.3. Исполнитель -
2. ЦЕЛЬ РАБОТЫ
2.1. Целью работы является ...
3. НАЗНАЧЕНИЕ РАЗРАБАТЫВАЕМОГО ПРОГРАММНОГО ПРОДУКТА
3.1. Разработка программного обеспечения для ... должно обеспечить уменьшение времени...
4. ТРЕБОВАНИЯ К РАЗРАБАТЫВАЕМОМУ ПРОГРАММНОМУ ПРОДУКТУ
4.1. Разработанное ПО ... должно включать в себя:
- ..
- ..
- ..
- ..
- ..
4.2. ПО .. должно обеспечивать возможность работы под управлением ОС ...
4.3. ...
4.4. ...
...
5. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
5.1. Документация на ПО ... должна быть разработана в соответствии с требованиями ЕСПД
5.2. Комплект программной документации (ПД) должен содержать:
- исходные тексты программ ПО ...;
- описание применения ПО.
5.3. Программная документация предоставляется Заказчику на магнитных носителях в 1 экз.
6. ЭТАПЫ И СРОКИ ВЫПОЛНЕНИЯ РАБОТЫ
6.1. .....
7. ПОРЯДОК ВЫПОЛНЕНИЯ И Сдачи работы
7.1. На приемку работы Исполнителем предъявляются:
- программная документация и исполняемые модули на магнитных носителях - 1 экз.
7.2. Данное техническое задание может корректироваться и дополняться установленным порядком.
Архитектуру системы
Детальное проектирование
Может объединить их в один раздел? или как подразделы в один
Вопросы конструирования
Непонятно какое имеет отношение к ПО. У меня сразу возникает ассоциация с конструкторской документацией
Конструирование скорее относится к аппаратуре, например конструирование корпуса изделия...
Результаты тестирования ...
Вот интересный раздел! Сюда студенты как правило втыкают какие-нибудь аляпистые формочки со всякими там наворотами и минимум текста. Возникает вопрос а нужен ли он? Может лучше сделать руководство пользователя.
...и соответствия заявленным требованиям (причем как мне кажется - это должен делать руководитель или рецензент)
Я вам сразу скажу что это превратится в банальное переписывание фраз из ТЗ
типа Требуется то-то... -> Выполнил то-то..
Кому из преводавателей охота выдумывать что-то для каждого студента? А если еще их с десяток?
Необходимую рабочую документацию, раскрывающие вопросы внедрения
что-то еще....
Сюда могут входить, например
Руководство пользователя
Руководство администратора
Руководство по установке (как правило реальный заказчик его всегда требует)
И, возможно, руководство программиста.
Что-то можно вынести в приложения.
Причем последняя часть может сильно зависить от типа квалификационной работы и ее содержание может корректироваться
Мне кажется лучше предложить студенту на выбор методологию из нескольких вариантов. Пусть выберет понравившуюся. И, соответственно, создать каркас ПЗ для данной методологии с возможностью внесения изменений при согласовании с руководителем.
-
Простите за, возможно, слишком резкую критику :-)
-
Простите за, возможно, слишком резкую критику :-)
Да что Вы, Алексей, просто у меня инет работает с придурью, вренее не инет, а авторизация на прокси вуза. Совсем трафик-агент замучал. Такие фокусы начинаются вечером, что не до ответов.
Мне кажется форма представления ТЗ может быть разная, как в прочем и других документов. Опять же многое зависит от выбранной методологии, предпочтений рукводителя, его понимания, требований профилирующей организации, если студент выполняет эту работу там.
Кроме того, а зачем адаптировать ТЗ гостовское, надо его использовать и все. Все эти ГОСТы носят рекомендательный характер, мы ими можем рукводствоваться, а можем игнорировать.
Надо попытаться написать структуру вопросов, на которые студент обязан дать ответы в ходе выполнения дипломной работы. Следует учесть и разный характер работ, их ориентированность на прикладной, научно-изыскательский, учебно-методический, методологический и т.п. аспекты.
При описании результатов тестирования, конечно, студент может банально переписать содержание ТЗ. Однако тут и нужен руководитель. А если он и ухом не шевелит, то комиссия может проверить при желании на соответствие.
Хотя в прочем я не настаиваю, просто знаю, что многие руковдители просто читают записку и совершенно не смотрят на проект и его не тестируют. Хорошо, если студент делает реальный проект и у него есть реальный заказчик.
Насчет различных руководств - тут думаю все просто - оно должно содержать минимум сведений, чтобы можно было установить и начать работать с проектом без участия студента. А подробные руководства ни к чему - не тот уровень работ.
План выполнения работ может быть изложен подобно Образу решения по Вигерсу. Мне так очень нравится такой документ. Простой, понятный и очевидный.
-
Да что Вы, Алексей, просто у меня инет работает с придурью, вренее не инет, а авторизация на прокси вуза. Совсем трафик-агент замучал. Такие фокусы начинаются вечером, что не до ответов.
Понятно, у нас тоже есть проблемы
Мне кажется форма представления ТЗ может быть разная, как в прочем и других документов. Опять же многое зависит от выбранной методологии, предпочтений рукводителя, его понимания, требований профилирующей организации, если студент выполняет эту работу там.
Да но нужно,чтобы был костяк к которому можно дописывать свои пункты иначе студент растеряется.
Кроме того, а зачем адаптировать ТЗ гостовское, надо его использовать и все. Все эти ГОСТы носят рекомендательный характер, мы ими можем рукводствоваться, а можем игнорировать.
Там много воды. Нужны вам скажем требования к упаковке или маркировки изделия?
Надо попытаться написать структуру вопросов, на которые студент обязан дать ответы в ходе выполнения дипломной работы. Следует учесть и разный характер работ, их ориентированность на прикладной, научно-изыскательский, учебно-методический, методологический и т.п. аспекты.
Это правильно, но мне кажется достаточно сложно для студентов. Им нужны примеры шаблоны тогда они сделают быстро, иначе будут возится и в конце концов просто закажут диплом.
При описании результатов тестирования, конечно, студент может банально переписать содержание ТЗ. Однако тут и нужен руководитель. А если он и ухом не шевелит, то комиссия может проверить при желании на соответствие.
Хотя в прочем я не настаиваю, просто знаю, что многие руковдители просто читают записку и совершенно не смотрят на проект и его не тестируют. Хорошо, если студент делает реальный проект и у него есть реальный заказчик.
Вот-вот большинство так и делает
Насчет различных руководств - тут думаю все просто - оно должно содержать минимум сведений, чтобы можно было установить и начать работать с проектом без участия студента. А подробные руководства ни к чему - не тот уровень работ.
Почему же пусть приучаются писать реальную документацию к проекту, пусть упрощенную, но реальную. Ведь так стояла изначально задача:
Кроме того, ряд членов комиссии, люди с солидным опытом жизни, высказывали недоумения структуре записке: что это за Аналитическая проектная и технологическая часть - мол таких элементов в реальной практики оформления ИТ-проектов нет.
План выполнения работ может быть изложен подобно Образу решения по Вигерсу. Мне так очень нравится такой документ. Простой, понятный и очевидный.
не видел надо поглядеть...
-
Похоже дискуссия будет только между нами. А соответственно носить академический характер, но может и к лучшему...
Да но нужно,чтобы был костяк к которому можно дописывать свои пункты иначе студент растеряется.
Там много воды. Нужны вам скажем требования к упаковке или маркировки изделия?
Костяк есть в старой методичке вполне норальный костяк, написанный надо сказать на основании опыта других вузов. Другое дело, что это костяк нужно конкретизировать походу дипломного проекта. Что я лично и делаю.
С другой стороны студенты обучались на курсе Проектирование ИС, где им читался курс ведения документации проекта. Так что в целом костяк есть.
Это правильно, но мне кажется достаточно сложно для студентов. Им нужны примеры шаблоны тогда они сделают быстро, иначе будут возится и в конце концов просто закажут диплом.
Понимаете шаблонов масса. Шаблон от Вигерса, шаблон РУП, шаблон ОпенУП, ГОСТ наконец
Почему же пусть приучаются писать реальную документацию к проекту, пусть упрощенную, но реальную. Ведь так стояла изначально задача:
Ну раздел пользовательской минимальной документации есть. На защитах часто спрашивается, а где у вас справка по работе с системой. В этом смысле все в порядке.
Проблема в том, что записку студент пишет после того как сделает проект. Отсюда и проблемы, и получается так, что часть решений оказываются в техзадании, а часть требований вдруг становятся решениями.
Т.е. в ходе анализа методички + анализа того, что она должна содержать, приходим к мысли, что для начала надо посмотреть, а так ли учим и чему учим :-)
Можно соблюсти скажем формальные признаки оформления работы по ГОСТу, а содержание будет неверным.
Нужно стараться, чтобы диплом был тем документом, с помощью которого можно скажем развить задачу. Т.е. документирование должно быть понятным. А этого нет.
Я тут посмотрел коллекцию дипломов, которые я рецензировал из разных вузов - везде структура очень разная. есть близкая к ГОСТ. Однако содержательная часть довольно забавная - несколько примеров
3.3.1 Общие требования к системе
Система материальными ресурсами предприятия должна удовлетворять ряду требований предъявляемых к ней как системе удовлетворения информационных потребностей на предприятии. Определим их:
1. Необходимость системного подхода, который проявляется в комплексном решении задач в подсистеме, в установлении границ изучаемого объекта, в установлении взаимосвязей информационных потоков внутри подсистемы и с внешней средой;
... 5. Экономичность подсистемы, что означает минимум затрат связанных с ее функционированием;
6. Проектируемая система должна обеспечить информацией, удовлетворяющей требованиям полноты, достоверности, точности, своевременности.
как это можно понять? и использовать?
Дизайн пользовательской части системы не должен вызывать негативных реакций и отторжения у пользователя, должен соответствовать общей концепции системы.
Модель пользовательского интерфейса системы должна соответствовать общепринятым стандартам в этой области.
совершенно инертная формулировка
3.3.1.9 Требования по стандартизации и унификации
ИС должна обеспечивать:
• Совместимость по форматам и процедурам обмена с другими подсистемами предприятия;
Каким таким форматам и процедурам?
Думаю достаточно. Т.е. дух диплома, его ТЗ выдержан в стиле ГОСТ. Однако понимал ли студент, что он пишет? Вот он и отмазался, используя какие-то примеры.
Вообще обсуждение как мне кажется позволило понять проблему, которая вовсе не в плохой методичке...
-
Вот какая мысль пришла в голову.
Дискуссия по поводу содержательной части рекомендаций к дипломному проектированию с моим коллегой зашла в тупик.
Коллега настаивает на использовании ГОСТ, как единственной разумной альтернативе при описании и документировании цикла разработки АС или АИС.
Я считаю, что альтернатив несколько - они могут определяться общей методологией разработки или процессом разработки.
Коллега утверждает, что одно другому не противоречит.
Я полагаю, что ГОСт - является методолгией структурного подхода, а следовательно у студентов, практикующих объектный подход, возникнеть необходимость затрачивать определенные усилия для адаптации используемого подхода или методологии к ГОСТу.
Однако, обратите внимание, что все существующие западные альтернативы направлены на то, что называется software - а это программное обеспечение и программные средства.
Последние входят как важная, но составная часть в информационную систему.
Поэтому требования к ИС неравны требованиям к программному обеспечению, и требования к программному обеспечению есть подмножество требований к ИС.
Исходя из этой логики, получается коллега прав, утверждая необходимость использования ГОСТов. Например, модель FRUPS+ не содержит таких понятий как организационное обеспечение, правовое обеспечение и некоторые другие. Или же я не прав, и все это входит в раздел business rules?
Стоит ли при разработки АИС учитывать главным образом вопросы разработки software.
Можно ли полагать в настоящий момент, что АИС - просто некоторый класс software?
Кто что думает по этому поводу?
-
А кого готовите-то? "Информационные системы и технологии" - это слишком общее название. Как специальности называются?
-
А кого готовите-то? "Информационные системы и технологии" - это слишком общее название. Как специальности называются?
Специальность так и называется. Она определена направлением 230200 Информационные системы и имеет название 230201 Информационные системы и технологии. Данное направление формирует куст специальностей Информационные системы в..., а специальность Информационные системы и технологии как раз первая.
Кого готовим вопрос? интересный, ибо я все 7 лет пытаюсь выяснить. Судя по чтению ряда экономических дисциплин - ближе к ИС в экономике. Анализируя программу, можно сказать специалист в области информационных систем ну а специализация у каждого может быть своя. Точно могу сказать не программистов, нет направленности на архитекторов. Скорее все-таки аналитиков, возможно архитекторов баз данных.