Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Galogen

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »
5806
Так народ не хочет отвечать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да нет, мы просто уже потеряли канву исходного посыла. Пост назывался "Крик души" - я изложил проблемы и попытался получить помощь в из преодолении. В ходе дискуссии возникла идея разработать методику преподавания. Денис предложил назвать нашу тему так как она сейчас и называется, видимо под впечателением инструментов,которые я использую.
Могу сказать, что я готов отказаться от всех этих инструментов одномоментно, однако к этому не готовы наши преподаватели на высших курсах. Здесь тонкость является в том, что я не могу отвечать за других, но вынужден учитывать их наработки. Т.е. если я к примеру полностью перейду на 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
Все-таки настаиваю не завершать конечным обезличеным состоянием, а показывать что будет после успешной и неуспешной регистрации. А то не понятно, после успешной регистрации что дальше? остаемся на тойже странице, возвращемся на главную как не зарегистрированный пользователь или появляется приветстиве - типа спасибо за регистрацию вы можете сделать то-то то...

5819
Саша, понимаешь русское прочтение слово дизайн и английское слово 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
Прежде чем ответить на твои другие вопросы, я хотел для начала высказать некоторое мнение.

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

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

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

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

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

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »