4906

Сообщество Аналитиков / Re: Ваши проблемы и задачи

« : 21 Сентября 2007, 17:14:17 »

Подарила бы, но у меня PDF версия, могу подарить и такую если надо.

Ой это pdf версия такая страшная, если она именно та :-)

4907

Обучение / Re: Требование к содержанию квалификационной работы

« : 21 Сентября 2007, 17:13:30 »

Похоже дискуссия будет только между нами. А соответственно носить академический характер, но может и к лучшему...

Да но нужно,чтобы был костяк к которому можно дописывать свои пункты иначе студент растеряется.
 Там много воды. Нужны вам скажем требования к упаковке или маркировки изделия?
 

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

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

Понимаете шаблонов масса. Шаблон от Вигерса, шаблон РУП, шаблон ОпенУП, ГОСТ наконец
 

Почему же пусть приучаются писать реальную документацию к проекту, пусть упрощенную, но реальную. Ведь так стояла изначально задача:

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

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

Т.е. в ходе анализа методички + анализа того, что она должна содержать, приходим к мысли, что для начала надо посмотреть, а так ли учим и чему учим :-)

Можно соблюсти скажем формальные признаки оформления работы по ГОСТу, а содержание будет неверным.

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

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

3.3.1   Общие требования к системе

Система материальными ресурсами предприятия должна удовлетворять ряду требований предъявляемых к ней как системе удовлетворения информационных потребностей на предприятии. Определим их:

   1. Необходимость системного подхода, который проявляется в комплексном решении задач в подсистеме, в установлении границ изучаемого объекта, в установлении взаимосвязей информационных потоков внутри подсистемы и с внешней средой;
...     5.  Экономичность подсистемы, что означает минимум затрат связанных с ее  функционированием;

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

как это можно понять? и использовать?

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

совершенно инертная формулировка

3.3.1.9 Требования по стандартизации и унификации

ИС должна обеспечивать:
•     Совместимость по форматам и процедурам обмена с другими подсистемами предприятия;

Каким таким форматам и процедурам?


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

4908

Сообщество Аналитиков / Re: Ваши проблемы и задачи

« : 21 Сентября 2007, 16:45:51 »

Какой ты меркантильный, можно было бы и подарить

Саша ты об чем, вроде и написано ПОДАРИТЬ :-)

4909

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

« : 21 Сентября 2007, 16:43:42 »

Круто. И такое было

А я еще и на фортране писал, еще в машинных кодах изгалялся на  ДЗ-38. Ну и на аналогывх компутерах успел поиграться в сласть на занятиях по общей химической технологии. Боже! неужели я такой старый? %)

4910

Системный Анализ и Требования / Re: Проблемы согласования документа с Заказчиком

« : 21 Сентября 2007, 07:57:02 »

Абсолютно не согласен. Не корректное сравнение. Цена ошибки не сопоставима!

Конечно, Вы правы, ситуации не сравнимы.

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

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

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

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

Современная практика как мне кажется, тоже вернется возможно к этому.

4911

Системный Анализ и Требования / Re: Проблемы согласования документа с Заказчиком

« : 20 Сентября 2007, 19:33:20 »

ArtemyY, вот давайте рассмотрим ситуацию.

Заказчик (З) - некто, кто желает пошить себе костюм.

Разработчик (П) - некто, кто шьет ему костюм.

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

Заказчик пришел к портному.

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

приходит срок примерки
П надевает на З костюм начинает его адаптировать по фигуре. З довольный уходит. П назначает срок изготовления
З приходит примеряет все отлично

Обычный процесс верно? З взаимодействует с человеком и он абсолютно не знает как ведется процесс, сколько человек готовит его костюм, как вообще шьется костюм

Представим другую ситуацию.

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

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

4912

Системный Анализ и Требования / Re: Проблемы согласования документа с Заказчиком

« : 20 Сентября 2007, 18:56:10 »

Изначально термин "адаптированный документ" возник в ответе Galogen'а:Здесь речь про то, что если "заказчик UML не понимает", то надо написать требования тем языком, который он понимает. Но мне в данном случае кажется, что порядок действий несколько перепутан. Опять же, сошлюсь на "буквари", требования изначально и должны излагаться на языке бизнеса. Именно так, чтобы их понял прежде всего заказчик. А дальше вы можете уже для проектной команды сделать отдельный документ, где перевести все требования на технический язык.

Каюсь, Михаил. Действительно вы правы. Контекст вопроса увел от истинного пути.

Однако есть вопрос, описать требования на языке заказчика, а какова степень детализации? Где та грань, за которой мы описываем требования уровня заказчика и не вносим требования уровня системы, на котором как раз актуальны разные схемы, нотации и прочее?

Насколько понятным путем текстовое структурированное описание бизнес-процесса в отличии от какой-то графической нотации?

Я просто примеряю ситуацию к руководству нашего вуза, т.е. достаточно консервативной аудитории топ-менеджеров со своими представлениями?

4913

Обучение / Re: Опыт преподавания структурного анализа

« : 20 Сентября 2007, 16:36:51 »

P.S. Так сказать подытожить ваш опыт. Есть интерес попробовать вашу методику в следующем семестре.

Понимаете тут методика интуитивная и основана на постоянном мониторинге ситуации. Она требует от меня максимальной концентрации и вовлеченности в работу.

1. Я стараюсь разбить весь курс на максимально большие куски. Кстати меня ругают за насыщенность, потому можно чем-то ограничится, что-то принести в жертву.

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

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

Теперь как делается в моем случае с задачей. Цель первого задания - ребята должны стать экспертами (пусть мнимыми) в своей предметной области. Как они это сделают неважно, как показал опыт у ребят хватает соображения понять, что от них хотят и придумать свой бизнес, свою предметную область. Этим они занимаются два занятия аудиторно и остальное время дома. Собираются ли они вместе или нет, делают они это через нетворкинг, используют они чей-то опыт, идут они на реальный объект и спрашивают там. Это неважно - главная установка - вы должны знать о своем предмете все, и все что вы знаетет это ваше сокровенное знание.
В ходе дискуссий на занятий, я подхожу к каждой группе и даю ряд рекомендаций. Главное говорю снять неопределенность, собрать информацию, придумать изобрести. Например задаю вопрос - вот вы кассир, а я покупатель,как происходит оформление покупки? ЧЯ подошел к кассе и даю товар - каковы ваши действия?
Или у вас сеть магазинов, как вы осуществляете поставки в магазины нужных товаров - мне рассказывают, я задаю какие-то вопросы, если мне что-то неясно, либо прошу членов группы самим задать вопросы совему оратору. рассказываю о принципах могзгового штурма, идею использования карт памяти. Говорю все что вы знаете, что придумали запишите на бумаге. Первое занятие обычно проходит бурно, я лишь наблюдаю и вклиниваюсь иногда. Второе занятие я прошу показать, что у них накоплено. Кстати сразу видно, кто как относится к делу, каковы привычки группы.

Например две группы вообще не принесли никаких документов, но довольно увренено отвечали на вопросы. Две другие группы очень хорошо подготовились, записали  ответы на вопросы, записали вопросы, на которые хотели получить ответы.

На третье занятие они принесли презентации на PowerPointe. Одна группа вообще сделала флэш-ролик и сразу задала особую атмосферу восприятия.

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

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

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

Первые два задания коллективные - оценку получают все одинаковые по успешности своих работ в колективе.

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

При этом инструмент имеет второстепенное значение, главное value.

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

4914

Обучение / Re: Требование к содержанию квалификационной работы

« : 20 Сентября 2007, 15:42:14 »

Простите за, возможно, слишком резкую критику :-)

Да что Вы, Алексей, просто у меня инет работает с придурью, вренее не инет, а авторизация на прокси вуза. Совсем трафик-агент замучал. Такие фокусы начинаются вечером, что не до ответов.

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

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

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

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

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

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

4915

Обучение / Опыт преподавания структурного анализа

« : 20 Сентября 2007, 10:19:16 »

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

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

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

Техника проведения эксперимента примерна такая же как для эксперимента преподавания объектно-ориентированного анализа:

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

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

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

Вчера состоялась первая отчетная презентация. Я очень доволен. В отличии от первого опыта весной этого года, в этом семестре ребята совершенно другие. К делу подошли очень творчески и подготовили просто шикарные презентации. Большинство не просто подготовили презентацию, а фактически разыграли определенные роли, очень живо и искренне.

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

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

Впредь планирую никак не сдерживать инициативу и творчество студентов.

2. Второе занятие преследует приобретение некоторых навыков анализа. Предлагается проанализировать имеющуюся информацию, выделить функции и данные, распределить, структуризировать, сгруппировать, приоретизировать. Подготовить контекст решаемой задачи, построить контекстную диаграмму IDEF0. Здесь я следую главным образом [urlhttp://www.isuct.ru/~ivt/books/CASE/case8/sadt/gl22.htm]де Марко[/url]

3. Задание - выделение проблемного БП или просто БП для последующего анализа и изучения в индивидуальном порядке (в моем случае парой студентов в рамках группового на 6-8 человек задания). Здесь нужно выделить не очень сложный, но достаточной важный БП. Подготовить модель "как есть" для него, составить описание процессов и функций его составляющих, разработать модели IDEF0 и IDEF3 и подготовить образ решения  по типу Вигерса (смотри прицепку)

4. далее предлагется придумать собственно решение, то есть придумать образ ИС, решающий вопросы БП. Предполагю делать это с использованием DFD вплоть до миниспецификации.

5. Построение информационной модели задачи - используется ERWin

6. разработка прототипа на Аксесс для понимания - а что получили?, и что бы хотелось еще получить?

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

4916

IDEF ARIS BPMN и пр. / Re: BPMN: gateway, event или conditional sequence flow?

« : 19 Сентября 2007, 19:28:26 »

Если слово "мама" перевести на несколько языков, изменится ли его смысл?

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

Поскольку результат действия Поиск документа однозначен - найден или не найден, то соответственно имеем исключающее ИЛИ, которое и реализуется разными способами.

4917

Системный Анализ и Требования / Re: Проблемы согласования документа с Заказчиком

« : 19 Сентября 2007, 17:57:14 »

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

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

Теперь насчет представления документа заказчику в виде UML, eEPC, IDEF0 и т.п. Да, конечно, заказчик совсем не обязан понимать все это, потому он должен требовать описания втакой форме, которую он понимает! Если это не возможно или обременительно )за предоставления адаптированного документа разработчик может потребовать некоторую сумму сверху), заказчик может воспользоваться услугами независимого эксперта или иметь в штате достаточно грамотного в этой области человека. Вне всякого сомнения заказчику совершенно не имеет смысла знать как разрабатывается ПО.

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

4918

Управление Проектом / Re: укрощение EPF Composer

« : 19 Сентября 2007, 16:37:39 »

Вижу, что Вы знакомы со словом Дилетант! Прошу прощения, если уязвил Ваше самолюбие!

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

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

EPF Composer вовсе не для дилетантов. Мне кажется, владение продуктом предполагает целый набор навыков: знание английского, понимание HTML, умение работать с формами и т.п. Это уже предполагает довольно грамотного пользователя, а учитывая направленность инструмента, и знания в области процессов разработки систем и ПО.

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

4919

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 19 Сентября 2007, 13:45:41 »

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

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

4920

Управление Проектом / Re: укрощение EPF Composer

« : 19 Сентября 2007, 09:26:09 »

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

SuijiuS, я бы попросил Вас избегать впредь подобных формулировок. Денис вовсе не высказывался в подобном стиле. Делитант - пишется дилетант