5806

IDEF ARIS BPMN и пр. / Re: Теория информационных процессов и систем (ТИПиС)

« : 12 Января 2007, 09:48:38 »

Так народ не хочет отвечать.

Ладушки. Продолжим экзекуцию :-)

Попытаемся понять каковы цели данной дисциплины, исходя из ГОС.
Основные задачи теории систем; краткая историческая справка; терминология теории систем; системный анализ
Дать основные положения теории систем и системного анализа: определения, закономерности, классификацию, структуру, задачи, практику применения.

понятие информационной системы; качественные и количественные методы описания информационных систем; кибернетический подход; динамическое описание информационных систем; каноническое представление информационной системы; агрегатное описание информационных систем.
Когда я готовился к лекциям, да и сейчас тоже, для меня вот это не особо понятно. Лично у меня такое ощущение, что автор ГОС, просто добавил прилагательное информационные.
Качественные и количественные методы описания ИС? Что это такое? Есть качественные и количественные методы системного анализа: мозговой штурм, Дельфи, дерево целей, экспертные оценки, теория полезности, подобия, оценивания и т.п.
Динамическое описание ИС - это что? Как это понимать?
Каноническое описание - искал - так и не нашел
Агрегатное описание ИС - вообще пустой звук. Что это - компоненты ИС?

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

Модели информационных систем; синтез и декомпозиция информационных систем; информационные модели принятия решений; возможность использования общей теории систем в практике проектирования информационных систем.
Тут мы дошли то сути:-)) Что такое модели ИС? Функциональные, структурные, поведенческие и архитектурные
Синтез и декомпозиция - что это ? методы, правила? техники...
Использование ОТС при проектировании ИС???

5807

UML SysML и пр. / Re: Класс-сущность, граничный класс и т.п.

« : 12 Января 2007, 09:32:55 »

Да, конечно. Класс-сущность отображает предметную область.

Насчет верстальщика и программера.

Что такое верстальщик - это все-таки не совсем просто дизайнер. Просто дизайнер - это фактически художник, который рисует вам дизайн в Photoshop к примеру. А верстальщик уже идею дизайнера воплощает в шаблон. А шаблон будет использовать html-коды - это уже разметка, это уже программа, css-стили, а это тоже требует ясного представления о сути проблемы.

Классическая архитектура приложения: логика представления(1 слой), бизнес-логика или программная логика работы системы(2 слой), логика данных скажем(или 3 уровень хранение данных).

Посмотрим как это зачастую реализуется например в Delphi:
Скажем есть база данных.
В приложении мы делаем: уровень подключение к БД - типа DataBaseConnection Transaction
Далее формируем DataSet - класс для доступа к набору данных и манипуляции с ним
DataSource - класс связывающийся с DaTaSet и фактически преобразующий сущности БД в сущности программы и не посредственно соединяется с элементами DataControl - поля, списки, гриды и тп.

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

5808

Примеры / Re: Электронное тестирование учеников

« : 12 Января 2007, 09:20:37 »

эти самые условия, их на какой дорожке надо рисовать?Наверно на системной?

Конечно на системной, условие определяет система.
Мне не понравилось, что вы завершаете отмену регистрации ромбом. Ромб - точка принятия решения. Обычно для слияния потоков используются жирная черная черта (правда если идут параллельные потоки). Хотя, имхо, иногда можно отойти от стандарта, тем более если все ясно и понятно...

5809

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 11 Января 2007, 21:46:53 »

Дружище Galogen! Не стоит воспринимать вопросы, как критику. Никто тебя не критикует: у тебя свои цели и критерии, мы пытаемся понять, чего же ты хочешь получить на выходе.

Спасибо дружище Boatman. Да я не принимаю понимаю, что это не критика:-) Это я так, просто с досады, что не могу донести до вас картину того, что у меня есть, в какой ситуации я нахожусь, и прочее. Я даже скажу более, будем считать - что я вообще круглый дилетант, так оно в общем и есть, поскольку варюсь-то я в своем соку.
Единственно, что все во мне против, так это такого вот скрупулезного анализа. Вернее я за него, но не через меру:-))

Цели уточняются - это хорошо. правильно ли я понимаю, что ты хочешь привить навыки применения SADT путем моделирования бизнес-системы в IDEF0,IDEF3 с переходом к DFD с переходом к IDEF1 и финальным получением физической схемы базы данных для верификации результата (в данном случае в MS Access)? Давай все таки напряжемся и сформулируем задачу парой фраз, к которым был бы трудно придраться и там было бы ровно то, что ты хочешь сделать.

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

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

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

Дальше по другим вопросам:
1. список тем я выпишу, если это действително надо, вроде как лекционный курс тебя устравает, если я все понял правильно.
2. Концепцию складской системы допишем
3. С меня этюд про уравнение.
4. Что еще мы точно будем делать?
5. Как ты относишься к предложению по созданию бизнес-процессов и моделированию их с помощью ролевой игры? Этот вариант отвергнут или можно копать в этом направлении?

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

5810

О Сайте и Форуме / Re: Структура файлового каталога электрокниг

« : 11 Января 2007, 19:43:58 »

Денис, ВЫ администратор. Пользуйтесь своими правами с достоинством и осторожностью:-))

5811

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 11 Января 2007, 19:39:33 »

Ваши слова кстати напоминают ещё особенность в понимании термина БД у представителей малого и иногда среднего и даже большого бизнеса - они, бывает, говорят "нам нужна БД того-то"

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

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

Кстати я опубликовал две темы, одна из них Теория информационных процессов и систем - прошу высказываться о наполнении предмета там.

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

5812

О Сайте и Форуме / Re: Структура файлового каталога электрокниг

« : 11 Января 2007, 16:36:14 »

Структура мне нравится, остается ее сделать, нужно волевое решение администратора и владельца, и назначить исполнителя:-)) Я чур пас

5813

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 11 Января 2007, 16:21:39 »

Сергей, кажется я понял предмет нашего разногласия и непонимания.

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

5814

Бизнес-анализ и Целеполагание / Гибкое бизнес-моделирование

« : 11 Января 2007, 16:00:06 »

Представляю вам небольшую главу, посвященную гибкому бизнес-моделированию, из книги  Скотта Амблера "Гибкие технологии: экстремальное программирование и унифицированный процесс разработки". Издательство "Питер". 2005

Почитайте, выскажите свое мнение, если оно у вас возникнет:-))

5815

Книги, статьи и ресурсы / Re: Книги: Крэг Ларман. Применение UML и шаблонов проектирования

« : 11 Января 2007, 15:21:06 »

Хочу отметить, что все выше сказано относится к 1 изданию, 2 издание - опубликованое на сайте, здорово отличается.
Во-первых, рассматривается RUP процесс, а следовательно идеи 1 издания переработаны основательно.
Во-вторых, при описание прецедентов видно большое влияние Коберна, фактически идея Коберна в его книге: Современные методы описания функциональных требований к системе.
В -третьих, книга стала более насыщена, а ее терминалогия и графические нотации приближены к последним стандартам.

5816

Проектирование / Re: [Термин] Проектирование

« : 11 Января 2007, 14:58:23 »

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

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

5817

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 11 Января 2007, 14:54:13 »

Что-то у нас частенько меняется цель и направление движения. Сейчас у нас их несколько:- Разработать методику...- Разобрать практический пример...- Автоматизировать...и т.д.

Да нет, мы просто уже потеряли канву исходного посыла. Пост назывался "Крик души" - я изложил проблемы и попытался получить помощь в из преодолении. В ходе дискуссии возникла идея разработать методику преподавания. Денис предложил назвать нашу тему так как она сейчас и называется, видимо под впечателением инструментов,которые я использую.
Могу сказать, что я готов отказаться от всех этих инструментов одномоментно, однако к этому не готовы наши преподаватели на высших курсах. Здесь тонкость является в том, что я не могу отвечать за других, но вынужден учитывать их наработки. Т.е. если я к примеру полностью перейду на UML, а мои коллеги будут настаивать на использовании DFD, то получается довольна забавная ситуация. Надеюсь все-таки мы прийдем к некотрому знаменателю. Однако на мой взгляд, все используемые инструменты - просто инструменты, удобные или нет, кроме того, как кажется нужно дать общий багаж знаний. Ведь то, что классическая механика  не отражает реалии мира полностью, не означает, что мы ее должны отбросить и начать изучать только квантовую механику.

В посте, где я насчитал 7 тем я решил, что это он и есть (там выше ).

Не сочти за труд - опубликуй и выдели красным цветом:-))

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

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

Давай определимся среди вариантов:1. Речь идет об отношениях юридических лиц: поставщика и покупателя 2. Речь идет о двух юридических лицах: фирма и транспортная компания3. Речь идет о трех подразделениях одной организации: оптовый склад, транспортное подразделение, другой склад (склад магазина?)Так как я сейчас играю роль задающего вопросы, то отвечаешь на них ты. Выбирай вариант или предлагай иное...

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

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

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

Я чувствую, что в самом названии уже корень непонимания. Мы говорим о разных вещах. И я извиняюсь за то, что невнимательно читаю.

Давай отвяжемся от этого. Идем от СА применительно к построению систем. Обычно строят
функциональные модели - в качестве инструмента может выступать IDEF0 IDEF3, причем эти методологии более ориентированы на материальные системы
структурные модели - Idef1x ERD и некоторые другие, кто-то относит сюда и DFD
Поведенческие модели - модели поведения STD, конечные автоматы, но ведь и DFD
Архитектурные модели - тут можно использвать DFD вероятно что-то еще...
Я не замахиваюсь на весь цикл.
СФА - помоему показывает приоритет функции над структурой, какие функции реализуем такая и структура, а не наоборот, подгонка функций под структуру.

если следовать понятию Бизнес-модели: то диаграмма прецедентов - внешнее представление системы, модель бизнес-объектов - суть концептуальная ИЛМ, хотя и с поведением, но необязательно

Написано еще много чего. Но сейчас мой вопрос такой: действительно ли требуетсяметодика преподавания техник функционального моделирования и моделирования данных (IDEF, DFD) на примере построения OLTP приложения с клиент-серверной архитектурой для автоматизации бизнес-деятельности путем1. Моделирования бизнес-процессов и ER моделирования 2. Получения функциональных требований к системе (судя по всему требуется алгоритм вывода требований из ОБП и ERD я такого не знаю)3. Построения БД и создания клиентского приложения RAD средством MS Access (для верификации результата)

Не совсем так, хотя мы негласно и подразумеваем это, но на самом деле я не постулирую и не ориентирую студентов на построение такой системы. Во-превых и времени не хватит, во-вторых, просто еще не все знания получены, чтобы реально это сделать. просто перевод модели данных на Аксесс - некий вынужденный прием, чтобы студенты посмотрели что же у них получилось. Могут ли они сделать то, что как им кажется должно делаться.
Пример: студент моделирует процесс подачи заявления абитуриентом в вуз. В ходе анализа строит такую модель.
Абитуриент(№, ФИО, что-то еще)
Специальность (Код, Название, №абитуриента)
Т.е. делает связь 1-М от абитуриента к специальности. Т.е. читаем факт 1 абитуриент может подать заяление на много специальностей, обратно: На одну конкретную специальность может подать заявление только один абитуриент. Т.е. на стадии анализа - студент чего-то не понял. Для того чтобы не объяснять ему ошибку, я просто прошу его принять на специальность такую-то 10 абитуриентов. Он конвертирует совю логическую модель в БД аксесс и видит что не может этого сделать и быстро понимает что же он сделал не так

Насчет алгоритма вывода - не совсем так. задача функционального моделирования в понимании того, какие документы и данные циркулируют в системе, какие нужно сохранять, а какие нет, а также какие процедуры следует предусмотреть. При этом есть некое решение этого вопроса:
DFD - центры обратботки информации, сущности генерирующие или потребляющие информацию, хранилища - показывающие состояние потоков в определенный момент времени и сами потоки.
Информационный поток структурируется той информацией которую он переносит через использвание Arrowdata, хранилища  потенциальные таблицы. В Arrow Data мы прписываем связываем с неким потоком некотрую сущность и возможно ее атрибуты, кроме того может указать инструкции CRUD и IRUN. Далее словарь сущностей и атрибутов может быть сконвертирован в ERWIN модель - остается смоделировать связи. Такой подход имхо вполне логичен, правда я использую подход анализа документов, которые им даны или которые им предлагается разработать исходя из логики задачи.

5818

Примеры / Re: Электронное тестирование учеников

« : 11 Января 2007, 14:07:06 »

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

5819

Проектирование / Re: [Термин] Проектирование

« : 11 Января 2007, 14:01:17 »

Саша, понимаешь русское прочтение слово дизайн и английское слово design, не совсем эквивалентны

Вот небоьшая ввыписка из словаря.

design I [dI'zaIn] n
1.   1) замысел; план
far-reaching designs - далеко идущие замыслы
to have a design for /of/ an insurrection - планировать восстание
to frustrate smb.'s designs - сорвать чьи-л. замыслы /планы/
2) часто pl (злой) умысел
criminal design - преступный замысел
to harbour designs - вынашивать (коварные) замыслы
to have designs on /against/ smb. - вынашивать коварные замыслы против кого-л.
to have designs on smb.'s life - покушаться на чью-л. жизнь
3) рел. божье провидение, божественный промыс(е)л
2.   цель, намерение
stern design - твёрдое намерение
the designs of France - намерения Франции
with this design - с этой целью
with (a) design - с намерением, с целью
without design - без всякого намерения
by design - намеренно; преднамеренно, предумышленно
it was done by design - это было сделано намеренно
my design was to go to London - я собирался поехать в Лондон
3.   1) (творческий) замысел; план, проект
the composer's design - замысел композитора
conceptual design - эскизный проект
2) планирование
design of experiments - планирование экспериментов
3) вчт. проектирование; конструирование
computer design - проектирование или конструирование вычислительных машин
design engineer - (инженер-)конструктор
on-line design - оперативное проектирование (в режиме взаимодействия человека с машиной)
4.   1) чертёж, эскиз; конструкция; проект; расчёт
antiseismic design - антисейсмическая конструкция
design office - конструкторское бюро
design drawing - рабочий чертёж
design conditions - исходные условия расчёта
design load - расчётная нагрузка (самолёта, корабля)
design for a building - чертёж здания
2) рисунок, узор
design of flowers - узор из цветов
(of) poor design - плохо выполненный, бедный, бедного рисунка
(of) fine design - прекрасно выполненный
arts of design - изобразительные искусства
school of design - школа изобразительных искусств, художественная школа
3) модель
our latest design - наша последняя модель
car of the latest design - последняя модель автомобиля
4) композиция
the picture lacks design - в картине есть композиционные недостатки
5) искусство композиции
5.   дизайн; внешний вид, исполнение
industrial design - промышленная эстетика
in marketing an article design is as important as construction - для коммерческого успеха товара дизайн имеет такое же значение, как конструкция
6.   произведение искусства

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

Вот что пишет господин Ларман в совей книге Применение UML и шаблонов проектирования

1.3.  Что такое анализ и проектирование
Для создания программного приложения необходимо описать проблему и требования к системе. Этап анализа (analysis) состоит в исследовании проблемы, а не в поисках путей ее решения. Например, при разработке новой информационной системы для компьютерной библиотеки необходимо описать экономические процессы, связанные с ее использованием.
При разработке приложения необходимо также обеспечить высокий уровень и подробное описание логики решения, удовлетворяющего требованиям к системе и налагаемым ограничениям. В процессе проектирования (design) основное внимание уделяется логическому решению, обеспечивающему выполнение основных требований. Например, как на самом деле будет функционировать информационная библиотечная система? Безусловно, проект может быть реализован в виде аппаратных средств и программного обеспечения.

5820

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 11 Января 2007, 13:11:59 »

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

1. Системный анализ = моделирование до некоторой степени. А может и полное тождество в нашем случае. Моделирование - это процесс построения модели М для реального объекта исследование S с точностью А. Думаю точность определяется целями моделирования, т.е. что мы хотим от этого процесса. В нашем конкретном случае мы хотим фактически автоматизировать ввод, хранение и предоставление информации от поступлении на склад  и изъятии книг со склада. Важной составляющей является информационные потоки или потоки документов, которые должны быть созданы в процессе или которые будут использоваться в процессе. Мы определяем в начале, что же мы хотим знать:
1/ общее количество книг на текущий момент
2/ количесвто книг поступивших в период времени
3/ количесвто книг по категориям
4/ количество книг по названи
5/ цену покупки книги
6/ место где она хранится
7/ остатки
8/ кто поставщик или издательство
Для решения этой задачи безусловно нужно рассматривать как поступление, так и изъятие. В реальной практике - это может быть сложный и многоаспектный процесс, однако в нашем случае - мы можем абстрагироваться от деталей и упростить ситуацию до простейшего поступления книги или партии книг и их изъятия куда-то, куда не важно - мы просто фиксируем два основных факта: приход книги - уход книги.
наша задача отобразить эти факты в нашей системе, системе учета прихода-расхода.
При описании процесса мы можем дать волю фантазии, а можем особо не задумываться о том, как каким образом узнается, определяется скажем место положение конкретной книги, ее идентификатор и т.п. С другой стороны, это кажется важным как происходит присваивание новым поступлениям номенклатурного номера и определяется место хранение. Формируется ли это после ввода в документ системы, где система автоматически назначает соотвествующий номер и определяет место хранения (ящик, полка, стойка, стеллаж) - однако нас пока не интересует факт реализации, мы можем просто констатировать, что
при вводе нового товара ему присваивается некий новый номер
при вводе товара следует указать место его хранения
номер определяет всю поставку (20 книг в упакове - одного и тогоже автора и названия) или можем потребовать чтобы каждая книга имела свой номенклатурный номер.
Т.е. мы должны определить бизнес-правила того как формируется документ.

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

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

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

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

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