У меня в вузе со студентами, обучающимися по дисциплине "Проектирование ИС", возникла забавная дискуссия. Суть ее приведу после, однако результатом ее стала потребность начать эту тему.

Не хочу писать свои мысли по данному вопросу, чтобы случайно не увести дискуссию по "ложному следу". Но вот хотелось бы понять:

1. Что такое проект?

2. Что такое проектирование информационной системы или программного обеспечения?

3. Какие вопросы, на ваш взгляд, должен освещать данный предмет в вузе или в учебнике?

1. Уже обсуждалось, поищи на форуме
2. Для меня - это фаза Design
3. Ну соотвественно п. 2

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

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

Вот у нас сейчас в команде есть уже более-менее понятные роли аналитика, программиста и тестировщика. А отдельной роли проектировщика нет. Какое-то проектирование (в смысле условного этапа между сбором требований и программированием) мы, конечно, выполняем, обычно на совещаниях. Можно даже "для красоты" сказать, что эту роль играет вся команда. Это на самом "крупном" уровне, более "мелкие" задачи по проектированию выполняет сам программист. Но каждый раз при выборе проектных решений мы руководствуемся только предыдущим опытом и здравым смыслом. Никаких теорий, формальных моделей или твёрдых принципов при этом не используется.

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

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

По первым двум вопросам,не скажу больно уж широкие/глубокие:). А для студентов лучше всего будет несколько примеров из жизни по разработки ИС, при чем полный цикл.Ну правда перед этим надо теории дать.

ЗЫ:У меня в вузе по проектированию ИC голая теория со страшными терминами, как результат в голове ни чего из того курса не осталось.

Я, пожалуй, продолжу с некоторой теоретической справки. (Мы действительно обсуждали уже вопрос понятия проекта)

Начну с философов.  А.М. Новиков. Д.А. Новиков Методология.

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

стр. 32 Проектирование процессс целеполагания (в категориях системного анализа)
стр. 44 Проектирование - начальная фаза проекта
стр. 258 Четкого определения нет, но говорится о фазе проектиования, которая включает стадии: концептуальную, моделирования, конструирования и технологической подготовки

Теперь обратимся к учебнику Ведрова. Проектирования ПО ЭИС. Учебник есть в библиотеке и рекомендован студентам. Правда в библиотеке старое издание от 2000 года кажется, я же привожу цитаты из учебника от 2006

стр. 10-11 Но определению Института управления проектами (Project Management Institute, PMI), проект — это временное предприятие, осуществляемое с целью создания уникального продукта или услуги. В любой инженерной дисциплине под проектированием обычно понимается  некий унифицированный  подход, с  помощью которого мы ищем пути решения определенной проблемы, обеспечивая выполнение поставленной задачи. В контексте инженерного проектирования можно определить цель проектирования как создание системы, которая:
• удовлетворяет заданным (возможно, неформальным) функциональным спецификациям;
• согласована с ограничениями, накладываемыми оборудованием;
• удовлетворяет явным и неявным требованиям по эксплуатационным качествам и потреблению ресурсов;
• удовлетворяет явным и неявным критериям дизайна продукта;
• удовлетворяет требованиям к самому процессу разработки, таким, например, как продолжительность и стоимость, а также привлечение дополнительных инструментальных средств.
В другой формулировке цель проектирования - выявление ясной и относительно простой внутренней структуры, называемой архитектурой системы. Проект есть окончательный продукт процесса проектирования. Проектирование подразумевает учет противоречивых требований. Его продуктами являются модели, позволяющие понять структуру будущей системы, сбалансировать требования и наметить схему реализации.
Таким образом, под проектом ПО будем понимать совокупность спецификаций ПО (включающих модели и проектную документацию), обеспечивающих создание ПО в конкретной программно-технической среде.
Проектирование ПО представляет собой процесс создания спецификаций ПО на основе исходных требований к нему. Проектирование ПО сводится к последовательному уточнению его спецификаций на различных стадиях процесса создания ПО.

Так же приведу циататы из учебника Смирновой Г.Н. Проектирование ЭИС

стр. 27-28
Для теории принятия решении процесс проектирования ЭИС - это процесс принятия проектно-конструкторских решений, направленных на получение описания системы (проекта ЭИС), удовлетворяющего требования заказчика.

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

Под проектированием ЭИС понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом в проект ЭИС. С этой точки зрения проектирование ЭИС сводится к последовательной формализации проектных решений на различных стадиях жизненного цикла ЭИС: планирования и анализа требований, технического и рабочего проектирования, внедрения н эксплуатации ЭИС.

Ну а что мешает залезть в словарь?

Ничто не мешает. Правда хотелось бы услышать мнение самих участников.

Кажется, пришла пора пояснить в чем проблема.

Я преподаю КИС, но не проектирование ИС. Однако в моем курсе я рассказываю о внедрении систем автоматизации управления на предприятиях.
Зашел разговор о том, что же такое проект.

Студенты как один: проект это документация.

Я согласился, но попросил развить мысль: только ли документация, какова ее цель, и какая документация и почему.

Внятного ответа не получил. Спросил что понимается под проектированием.

Ответ - процесс создания документации, т.е. проекта.

Спросил, а что такое разработка. Какие модели ЖЦ разработки вы знаете.

Для начала никто не мог сказать, что такое ЖЦ, соответственно ни слова по поводу того, какие модели ЖЦ бывают.

Посмотрев лекции по проектированию ИС  я действительно увидел освещение вопросв связанных с документацией по ГОСТ 34 и то не очень точно. Например в лекция была фраза, что ТЗ разрабатывается заказчиком с участием разработчика (тогда как ГОСТ 34 определяет строго наоборот)

Для справки приведу ГОС самого предмета:

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

Видим что проектная документация хотя и важна, но не единственна, и там есть много чего, что явно расскрывается смысл проектирования.

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

Я понимаю, что в лекциях осветить все вопросы невозможно, но лекция должна быть некоторым планом изучения дисциплины, давать установку на то, что следует изучать в первую очередь

В курсе совершенно не изучаются даже бегло что такое РУП, МСФ, Аджил и т.п.

В сегодняшней рассылке citforum анонс книги "Руководство командой разработчиков программного обеспечения. Прикладные мысли.":
http://citforum.ru/SE/project/teams/
Там же ссылка на саму книгу в формате PDF.

Цитата:

Существующее состояние Software Engineering напоминает мне большую поваренную книгу с многочисленными описаниями рецептов однажды успешно приготовленных блюд из ингредиентов, которых у меня никогда в будущем не будет.

Например в лекция была фраза, что ТЗ разрабатывается заказчиком с участием разработчика (тогда как ГОСТ 34 определяет строго наоборот)

Вообще-то это беда, что в ГОСТе написано... Правда в Приложении к ГОСТ 34.602-89 на ТЗ, где указано, что ТЗ делает разработчик, приписано, что это рекомендуемый порядок. На практике трудно себе представить, чтобы при организации конкурса, участники конкурса каждый сначала независимо донимал Заказчика своими интервью, а потом участники конкурса "мерялись" бы теми ТЗ, что у них получились. ТЗ на конкурс, сейчас, как правило, предлагается уже готовое. А участники конкурса уже делают предложения по реализации требований (типа предпроект или "натягивают" на требование свой набор типовых и уже документированных решений).

По идее
1. сначала формируется представление о системе в целом (Эскизный проект). Начальство очень любит при всяких приемках и утверждениях читать эти документы .
2. потом прорабытваются  детали (пишется задание/ТЗ на их проектирование) из которых собственно система состоит и/или пишется заказ на приобретение готовых (Технический проект).
3. Потом "Рабочую документацию" пишут. В ГОСТ 34 про это сказано, но немного "размазано" - там и на стадии эскизного проекта в п. 4.2 пишут "документацию на АС и её части" и потом то же самое в п.5.2 продолжают на стадии Технического проекта....
Такая схема процесса принята и в зарубежной практике сооружения объектов (у них construction - это не только строительство- building, из камня, но и чисто из металла может быть). Высоко ценятся люди с опытом Front end engineering (FFED)  - это типа нашего этапа ГОСТ "Разработка концепции АС".

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

Shur, утро доброе

Пытался ответить вчера, не смог запостить сообщение.

Я согласен, что ГОСТ рекомендует, но не определяет на 100% кто готовит ТЗ.

Вы пишите, что практика такова, что ТЗ все-таки пишет Заказчик и согласует его с Разработчиком.
Хорошо. Тогда раз Заказчиком проекта выступает преподаватель, то он и должен формировать это ТЗ. Более того в лекции он это утверждает как распространенную практику. Отчего же заставляет студента формировать это ТЗ, да еще следит, чтобы оно соответствовало ГОСТ. ИМХО, пусть и готовит ТЗ на каждую курсовую и уже проверяет проект на соответствие ему Однако практика учебных занятий такова, что все делает студент - придумыает себе задачу, пишет ТЗ, пишет проект.
Такое безусловно также имеет место быть в реальной жизни.

С последним абзацем полностью согласен. Нельзя преподносить информацию вырванную из контекста. Различная документация - есть результат определенных действий, однако не цель этих действий.

Вообще это беда современных образовательных программ. Они за частую не просто абстрактны, а вообще не кладутся на существующую практику.

To Boatman, привет
Не согласен с тобой по поводу размытости философских утверждений - на мой взгляд они вполне конкретны. Просто у Новиковых сделан упор на проект - как процесс, программу деятельности.
А у Вендрова со Смирновой - как результат некоторой части этого процесса.

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


Потому я и спрашиваю аудиторию, учитывая, что предмет Проектирование рассчитан на 200 часов (100 часов аудиторных и 100 самостоятельных), каково его содержание должно быть по вашему. Какие разделы и вопросы следует освещать?

Shur, утро доброе

Пытался ответить вчера, не смог запостить сообщение.

Я согласен, что ГОСТ рекомендует, но не определяет на 100% кто готовит ТЗ.

Вы пишите, что практика такова, что ТЗ все-таки пишет Заказчик и согласует его с Разработчиком.
Хорошо. Тогда раз Заказчиком проекта выступает преподаватель, то он и должен формировать это ТЗ. Более того в лекции он это утверждает как распространенную практику. Отчего же заставляет студента формировать это ТЗ, да еще следит, чтобы оно соответствовало ГОСТ. ИМХО, пусть и готовит ТЗ на каждую курсовую и уже проверяет проект на соответствие ему Однако практика учебных занятий такова, что все делает студент - придумыает себе задачу, пишет ТЗ, пишет проект.
Такое безусловно также имеет место быть в реальной жизни.

Я бы уточнил ГОСТ в том смысле, что написание ТЗ также может производиться по заказу Заказчика. Но заказ на оформление требований (ТЗ) и заказ на проектирование системы в соответствии с ТЗ имеет смысл реализовывать как разные заказы, выполняемые разными исполнителями. Для написания ТЗ больше востребованы услуги бизнес-аналитиков, проектирование конкретных решений по этому ТЗ - скорее работа архитектора (системного аналитика).  Возможно и при обучении в институте имеет смысл на уровне конкретных заданий студентвм артикулированно разделять эти работы. Вплоть до того, что один студент оформляет ТЗ, а другой - проект по этому ТЗ.
Учитывая, что в жизни эти процессы разнесены (т.е. начинать проектировать надо когда ТЗ уже готово), проекты могут делаться по ТЗ, составленными студентами в предыдущие годы.
Неразличение задач формулирования ТЗ (требований) и собственно проектирования приводит в жизни, как правило, к перекосу в сторону насыщения ТЗ детальными требования по реализации системы. Особенно, если ТЗ пишет тот,кто по нему будет делать систему. Спецализация по написанию ТЗ по идее должна быть востребована для ИТ-подразделений компаний, занимающихся скорее эксплуатацией ПО и оборудования и обслуживанием пользоваталей, чем его разработкой. Если на такую работу брать людей, которые мечтают разрабатывать программы, а поддержку существующего ПО воспринимают как каторгу, то при написании ТЗ они пытаются неоправданно акцентировать технические детали проекта, мешая исполнителям-разработчикам. И не всегда качественно выполняют работу по сбору требований от собственной организции. Поэтому. в учебной ситуации ТЗ студент мог бы составлять и по требованиям, которые он должен узнать от преподаваталя, но модель их взаимодействия должна соответствовать ситуации общения косноязычного начальника и его подчиненного IT-ника  .
Говорят, раньше старались не брать в авиационно-технические училища ребят, которые мечтали стать летчиками. Потому что они, иногда, дорвавшись до самолета,  пытались таки осуществить свою мечту....

Золотые слова, Shur.

В начале этого года именно это я обсуждал с преподавателем. Обсуждение было жарким, однако ни к чему не привело.

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

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

Спасибо за мысль, попробую ее протолкнуть в массы.

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

Как же теперь всё запущено в нынешнем высшем образовании...

Расскажу коротенько, каким у меня было обучение, только это давно было:

Во-первых, на старших курсах у нас был курс, который назывался просто ЖЦРПО (там, конечно, были свои заморочки насчет "дискретно" и "несогласованно")
Во-вторых,  где-то параллельно в течение всего (!) учебного года выполнялась курсовая работа по разработке некоей программной системы.
В-третьих, эта работа выполнялась бригадой из 4-5-6 человек, состав бригады не менялся (разве что кого-то отчислят).
В-четвертых, были какие-то контрольные точки (своего рода зачеты), когда надо было сделать и представить какую-то часть работы преподавателю.

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

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

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

To Galogen:
Вы ведь действительно можете разделить свои классы курсовых во времени, и выдать (предварительно перетасовав) в качестве задания "проектировщикам" разработанные их товарищами ТЗ.

P.S. А, кстати, 200 часов - это один семестр или два?

To Galogen:
Вы ведь действительно можете разделить свои классы курсовых во времени, и выдать (предварительно перетасовав) в качестве задания "проектировщикам" разработанные их товарищами ТЗ.

Не могу к сожалению. Я же не одни препод на кафедре. 8 лет я пытаюсь договориться с другими на предмет вот такой перманентной работы. Чтобы тема была примерно одна, а разработка ее велась под разным соусом. Но не получается пока. У преподов так же, как и у студентов никакой особо мотивации.
Я и так уже из своих дисциплин сделал какой-то It-коктейль с разными нотками на разных дисциплин..

P.S. А, кстати, 200 часов - это один семестр или два?

2 (один) семестр 4 курса. Заканчивается курсовой по проектированию, причем параллельно идет бакалаврская.

Кстати в этом году я пытался сделать бригадный метод у 5 курсников. Получилось не очень плохо. Но и не шибко хорошо. Устраивать инквизицию не захотел, все-таки 5 курс. Кто захотел что-то получил, кто не захотел... "Ну даже аллах не может заставить осла напиться"

Мда...
IMHO одного семестра мало, а второй семестр 4-го курса - поздновато, чтобы начинать, т.к. голова у студентов уже чем-то другим занята.

Могу посоветовать уделить одну вводную лекцию теме "что такое ЖЦ (из чего состоит и как эти части связаны)", а также место и роль аналитика в нем, и, если получится, его (аналитика) возможные взаимодействия на различных этапах ЖЦ. Первое можно в контрольные мероприятия не включать, а второе - в определенном объеме можно. Ведь известно, что приходится сдавать - то приходится учить. Т.е. большая вероятность, что запомнят.

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

Водолей, Вам следует учесть, что я не веду этот предмет.

Я выходил с предложением переместить курс проектирования хотя бы на 1 семестр. Но не все так просто, тут есть свои тараканы.

Общие сведения о ЖЦ я даю в курсе теория информационных процессов и систем (3 курс 1 семестр). Затрагиваю элементы ЖЦ в крусе управление данными (2 семестр 3 курс). О роли аналитика пытаюсь рассказать в рамках курса Объектно-ориентированный анализ (2 семестр 3 курса).

Частично дублирую курс проектирование в рамках дисциплины корпоратинвые ИС (4 курс 2 семестр)