4801

О Сайте и Форуме / Re: День рождения сайта или что будем считать за эту дату?

« : 04 Ноября 2007, 14:31:40 »

Предлагаю отметить после семинара?!

Саня, сделай красочное объявление о праздновании годовщины.

4802

Примеры / Re: Примеры сказок, оформленных в виде UML диаграмм

« : 04 Ноября 2007, 00:50:50 »

Эд, супер. ))))
Все вроде даже правильно с точи зрения семантики
Единственное, что можно было бы сделать более глубокое наследование:
Живое существо->Человек
Живое существо->Птица->Курица
Живое существо->Животное->Мышка

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

4803

Примеры / Re: Примеры сказок, оформленных в виде UML диаграмм

« : 04 Ноября 2007, 00:43:00 »

Эд, А утешала Кура Ряба кого??

Поправил чуток

4804

Примеры / Re: Примеры сказок, оформленных в виде UML диаграмм

« : 04 Ноября 2007, 00:00:51 »

Сказка про курочку-рябу.

Жили-были дед и баба. Была у них курочка-ряба. Снесла как-то раз курочка-ряба яйцо да не простое, а золотое. Дед бил-бил, не разбил. Бабка била-била не разбила. Пробежала мышка, хвостиком махнула, яйцо упало и разбилось. Дед плакал-плакал, бабка плакала-плакала. Стала курочка утешать: "Не плачь бабка, не плачь дедка. Я вам еще снесу"

Все это финал

4805

Примеры / Re: Примеры сказок, оформленных в виде UML диаграмм

« : 03 Ноября 2007, 23:43:10 »

А по-моему, все классно. Разве только вот тянут-потянут, а вытянуть не могу, как-то надо по-другому. Т.е. дед подает команду - тянет-потянет. Репка - не могу

4806

Сообщество Аналитиков / Re: Визитки

« : 02 Ноября 2007, 23:15:26 »

Что-то идею с фотографией не очень понял...или ты и как виртуальную визитку ее хочешь использовать?

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

Но можно фотку поместить и прямо в визитку. Все таки человеческая память лучше фиксирует зрительные образы, чем текстовые

4807

Конференции Семинары и Тренинги / Re: [Семинар] - Альтернативные системы поддержки процесса разработки ПО (МСК)

« : 02 Ноября 2007, 22:59:43 »

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

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

Очень хочется услышать мнение практикующих специалистов

Думаю ответ по теме можно переместить в раздел управления проектами

4808

Нововведения / Re: SEC(R) 2007 - отчет и впечатление

« : 02 Ноября 2007, 22:55:32 »

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

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

4809

Обучение / Re: Дипломный проект как IT проект

« : 02 Ноября 2007, 20:30:50 »

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

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

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

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

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

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

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

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

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

4810

Конференции Семинары и Тренинги / Re: [Семинар] - Альтернативные системы поддержки процесса разработки ПО (МСК)

« : 02 Ноября 2007, 20:16:27 »

Саша, работа пошла

Хотелось бы уточнить. Если рассматриваются альтернативные системы поддержки, то существуют какие-то обще принятые. Нельзя ли огласить список. Или же под альтернативной понимается система Wiki+BugTraker+SourceControl, как бесплатная?

4811

Для всех / Re: Документация по результатам обследования и ее судьба

« : 02 Ноября 2007, 19:45:13 »

Концептуальный документ (Vision),
? Vision (знаю только Visio) что за оно
ссылку плиз почитаю

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

-- Концептуальным документом пользуются Аналитики и Заказчики
пару слов сюда расшифруйте КАК пользуются
особенно заказчики - ПРАКТИЧЕСКИ ? (кто)

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

Крэг Ларман, Лиффенгуэлл, Коберн, Кратчен, Рамбо, Блаха - кроме того можно посмотреть здесь: http://www.epfwiki.net/wikis/openupru/

4812

О Сайте и Форуме / Re: День рождения сайта или что будем считать за эту дату?

« : 02 Ноября 2007, 09:52:19 »

Вообще 1 пост на сайте был 27.10.2006 года - статья о проекте.
Ну а первый пост на форуме где-то в это время тоже
Если привязаться к дате 1 ноября - отличная идея.
Можно кстати сделать чуточку посложнее 1 суббота ноября :-)
В этом году будет 3 ноября :-)

4813

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 01 Ноября 2007, 20:41:46 »

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

4814

Обучение / Re: Дипломный проект как IT проект

« : 01 Ноября 2007, 10:44:55 »

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4815

Сообщество Аналитиков / Re: Визитки

« : 31 Октября 2007, 22:51:03 »

Вот пример визитки:
http://www.ljplus.ru/img3/r/e/reproachmind/card_filippov.gif

Номано. Визитка скромно и солидно. Я думаю прежде чем выпускать визитку надо немного формализовать логотип.
1. левую часть в целом можно оставить как есть. Разве поиграться с цветом и добиться большей четкости букв, на белом фоне нужно смотреть
2. Трехмерность букв UMLife надо либо передать неким значком в виде кубика - при этом нужно использовать не ортогональную. а аксонометрическую прямоугольную изометрическую проекцию или вообще перспективную проекцию. Сбалансировать логотип по освещению и тени
3. Договрится о цветах - например триколоре отражающим наше коммьюнити

После этого - сделать визитку.