Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Антонина от 21 Апреля 2011, 10:21:52
-
Доброе утро. Мне необходимо разработать ИС для строительной организации. Причем она является заказчиком. Работает с подрядными организациями на давальческой основе(т.е. сама закупает материал). Мне необходимо разработать ИС для отдела снабжения. Помогите, пожалуйста. Заранее благодарна.
-
диаграмма классов
-
ваши артефакты говорят о том, что у вас имеется какое-то представление о создаваемой системе (возможно обрывочное), и о том, что вы не знаете что теперь делать. предельно на примитивном уровне действительно уже что-то можно делать (например, для каждого "класса" разработать создание экземпляра, редактирование, удаление и как-то пытаться связать их во что-то единое). но я бы не рекомендовал так делать. нужно сначала разобраться в предметной области, чтобы система помогала работать. бардака там наверняка хватает, а бардак, как известно, невозможно автоматизировать.
но в целом - нагромождение какое-то... непонятно, что из этого (doc2) вы хотите реализовать в системе?
попробуйте все-таки пойти от рабочих процессов, для начала нарисуйте процесс в "квадратиках" (в эллипсах тоже можно :о))) и стрелочках, что за чем. не используйте термины будущей системы при этом - нарисуйте на бизнес уровне. потом отметьте те "квадраты", где будет использоваться система. определите список требований для каждого.
P.S. а готовых разве нет? дешевле обойдется.
-
я не нашла готовых
-
А вы не подскажете, может я вообще не в то напрвлении двигаюсь. Просто предметную область я знаю достаточно хорошо. я в ней работаю. Не могли бы сказать, что в ней в корне неверно?
-
я не нашла готовых
а какую задачу Вы решаете? было бы также полезно, чтобы Вы в двух словах рассказали о себе в том смысле, что у Вас за квалификация/опыт. ну и задачу желательно сформулировать внятно.
Не могли бы сказать, что в ней в корне неверно?
в ней: в предметной области или в диаграмме?
дело в том, что Вашей конкретики я, ессно, не знаю, просто по аналогии предполагаю наличие бардака, иначе система не понадобилась бы. возможно и схема мне кажется непонятной по той же причине, хотя знакомые слова я там нахожу :о))
думаю, что базовыми сущностями у вас могли бы быть: договор, оплата, поставка. разумеется, каждая из них "обкладывается" рядом вспомогательных сущностей, типа, заявок, накладных, платежей и т.п. если Вы аккуратно нарисуете свой процесс, где всё будет чётко описано, то станет достаточно очевидно, что из них и когда появляется, что на что влияет.
безусловно, Вам также будут нужны общесистемные справочники: клиентов, материалов и т.п.
потом Вы должны будете решить, что будет происходить в системе: какие бизнес-действия, выполняемые сейчас без системы, необходимо реализовать в системе для того, чтобы решить ту задачу, которая ставилась перед системой. возможно это повышение оборота денежных средств, может быть отсутствие в нужный момент необходимых материалов, может быть вопросы контроля качества материалов за счет контроля при заключении договоров с правильными поставщиками. это Вам лучше знать.
а пока здесь в лучшем случае могут помочь по синтаксису диаграмм, но Вы с ним и сами можете справиться. да и не в этом, по большому счету, дело.
-
Существует строительная организация, которая нанимает подрядные организации для строительства какого-либо объекта(ограждение, входная группа, внешнее газоснабжение и т.д.). Подряд может быть на основе давальчнского сырья, т.е. подрядчик каждый месяц составляет заявку на материалы, которые необходимы ему для строительства, строительная организация(заказчик) закупает эти материалы и передает их подрядчику по накладной. Для закупки материалов существует "отдел снабжения", которая ведет весь учет материала в экселевской таблице.
-
читаю книгу Леоненкова и на основе этой книги составила диаграмму БВИ.
-
про организацию более-менее понятно. в чем проблема? какие вопросы предметной области должны быть решены с помощью системы?
ведь автоматизация нужна не ради же самой автоматизации.
Вы - программист?
пример по диаграмме. у вас есть общее "оформление заказа", а также частные случаи: "оформление заказа материала" и "оформление заказа транспортных средств". видимо, вы хотели показать, что такого рода заказы выполняются похожим образом. (во-первых, это скорее всего не так, ну да ладно). но почему вы не стали "согласование условий" в различных случаях описывать аналогичным образом?
Понятно, что доставка у вас возможна разными способами, а "получение" в каждом случае делается по своему и настолько завязано с доставкой, что вы их показываете вместе? И что насчет "получения" при доставке поставщиком?
Кто получает счет на оплату? С оплатой вообще какая-то запутанная ситуация: кто кому и за что платит (в жизни понятно, а на диаграмме)?
-
вопросы должны быть решены следующие:
снабженцу необходимо вести учет материала, ослеживать его состояние, т.е. в заявке, заказан у поставщика, в доставке, на складе, передан подрядчику. предполагается, что снабженцу приходит заявка в бумажной форме, потом он сам создает форму заявки в системе, обрабатывает каждую позицию заявки.
обработка прдставляеься следующим образом: для каждого поставщика ведется учет заказанных материалов, его состояние, оплата и т.д. по мере поступления на склад необходимо отгружать материал подрядчику по специальной накладной на отпуск материала.
P.S. я не очень хороший программист. (наверное, Вы уже это поняли)
-
Мне объяснили, что доставка и получение это две неразрывные позиции. Т.е. в случае с поставщиком там происходит и получение (у самого себя) и доставка. А потом уже прием на складе
-
Оформление заказа я подразумеваю, что они мнеют общее: наименование(товара или услуги), кол-во(для товара-шт, для любой услуги так же могут быть шт, часы-для транспортных услуг), количество. А уже для заказа материала отдельно:срок изготовления, условия поставки. Для заказа транспортного средства-вид транспорта, грузоподъемность и т.д
-
Мне необходимо разработать ИС для строительной организации
Разработать или описать функционал?
Пример описания предметной области (http://www.interface.ru/fset.asp?Url=/misc/uml1.htm)
Во вложении посмотрите документ - наверно данную работу видели (к сожалению , работа без схем).
К сведению
читаю книгу Леоненкова и ...
Г.Буч, Дж.Рамбо, А.Джекобсон. Язык UML. Руководство пользователя. - это все-таки наверно получше.
-
мне необходимо именно разработать ИС.
-
ясно - организовать учет материалов.
предполагается, что снабженцу приходит заявка в бумажной форме, потом он сам создает форму заявки в системе, обрабатывает каждую позицию заявки.
откуда приходит? материализуется из ниоткуда? пусть лучше исходный заявитель вводит свою заявку в системе - это будет обоснованно. все равно заявитель каким-то образом формирует бумажную форму, с большой вероятностью печатает на компьютере - так какая разница в чем печатать: в ворде/экселе или сразу в системе с нужными справочниками.
а снабженец будет управлять каталогом материалов и состоянием склада.
обработка прдставляеься следующим образом: для каждого поставщика ведется учет заказанных материалов, его состояние, оплата и т.д. по мере поступления на склад необходимо отгружать материал подрядчику по специальной накладной на отпуск материала.
это понятно. "контроль исполнения заказов" называется. и "отпуск материалов".
я не очень хороший программист
дело не в программировании. здесь задача анализа. к программированию она имеет слабое отношение.
если в двух словах, то нужно сначала разобраться в задаче, понять что и откуда берется, что с чем и как связано, а потом уже рисовать схемы/модели, писать программу и т.п.
вижу необходимость нарисовать в "квадратиках" (пока речь только о последовательности действий на бизнес-уровне и о том, кто эти действия выполняет):
- получение заявки и формирование заказа
- контроль исполнения заказа
- еще, пожалуй, поступление материала на склад и
- отпуск материалов со склада.
сможете?
-
проблема в том, что эту заявку составляет обычно прораб подрядной организации. я не знаю, как мне заявителя и систему соединить.
я составляла диагрмму в rational rose. в "квадратиках" там же составлять? или просто визуально где угодно.
-
Мне объяснили, что доставка и получение это две неразрывные позиции. Т.е. в случае с поставщиком там происходит и получение (у самого себя) и доставка. А потом уже прием на складе
я не это имел в виду. во всех случаях написано "доставка и получение", а в одном только "доставка".
и потом, почему разделены получение и приемка на склад? где материалы находятся между этими операциями?
правильнее было бы их объединить - товар не потеряется и момент передачи ответственности, в т.ч. финансовой станет проще разруливать.
-
в квадратиках нужно для простоты вашего же (и нашего, моего) понимания - хоть в визио, хоть на листочке - не важно.
ведь модель/схема/диаграмма нужна для ответа на вопросы о предметной области, если с ее помощью можно ответить на вопросы к предметной области, тогда она подходит и по ней можно делать систему. если нет, то систему делать нельзя (точнее делать-то можно, но бестолку), т.к. работать с нею будет невозможно - она не будет соответствовать задачам предметной области. а до этого нужно упорядочить/стандартизировать саму предметную область, чтобы не было разночтений что и как делать в том или ином случае.
-
поняла. сейчас сделаю.
-
а прораб ее от руки что ли пишет?
если делегировать эту функцию (ввод заявки) снабженцу, могут возникнуть некоторые коллизии. например, прораб хочет заказать материал, которого нет (на складе, в каталоге или в природе). как-то должны оговариваться сроки получения прорабом заказанных материалов, а они должны увязываться с наличием, сроками поставки (в случае чего), созданием резервов, наконец.
если дать возможность прорабу самому заполнять заявку в системе, часть вопросов можно будет снять автоматически, например, ему можно будет показывать отсутствие нужного материала на складе и ожидаемый срок поставки. причем заказать материал, отсутствующий в каталоге он не сможет. и т.д.
однако, подрядных организаций несколько, расположены фигзнаетгде, прорабов много, все они разные. обеспечить доступный механизм создания заявок не очень просто с организационной точки зрения. технически как раз наоборот - web-страница.
какая-то аналогия - массовые продавцы техники и комплектующих, типа OLDI, PLEER и т.п. у них в офисе (торговом зале) стоят терминалы - можно завести свою заявку самому либо попросить об этом оператора. потом оплачиваешь в кассе и получаешь заказанное. в вашем случае теоретически возможна какая-то модификация подобной схемы.
только заявку должен заводить не сам снабженец (в том числе чтобы избежать злоупотреблений).... хотя.... все зависит от объема заявок, их сложности и т.п.
-
прораб пишет от руки. к сожаленью, подрядным организациям в основном некогда заниматься заявками. заявки пишет снабженец, со слов подрядчика.
составила "квадратики"
-
с поправкой: не "получение заявки", а "формирование заявки". транспортная компания конечно участвует в передаче материала на склад, да и доставки на схеме нет нет. что делает прораб при отпуске материала?
а в целом с точностью до синтаксиса можно было бы принять
получились функции процесса в предметной области.
дальше нужно было бы сделать две операции по расширению этой схемы:
- нужно дополнить ее документами, которые создаются, обрабатываются, порождают другие документы. например заявка создается на таком-то шаге, передается на такой-то шаг, на ее основании порождаются такие-то документы. в идеале (для проектирования это все равно понадобится) нужно было бы для каждого поля (атрибута) каждого документа провести анализ, откуда берется его значение (справочник там или ввод, есть ограничения или правила или нет и какие если есть), и в какие документы они "перетекают" - но пока этого можно не делать.
- расписать "из чего состоят указанные функции" на уровне действий/операций. например "формирование заявки" включает: создание новой заявки, заполнение заявки, утверждение заявки .... и т.п. - дополните/поправьте сами по тому, как происходит у вас.
-
т.е. нужно написать сценарий?
при передаче материала на склад прораб принимает материал,т.е. становится материально ответственным лицом.
как вы считаете, доставку добить отдельно?
-
и при отпуске, и при передаче материала прораб проверяет фактическое количество и наименование с тем, что написано в накладных.
-
нет, сценарий пока рано - это и будут ваши business use case. только они (в отличие от ваших исходных) будут ориентированы на отдельную задачу, определяемую эллиптическим "квадратиком".
-
и при отпуске, и при передаче материала прораб проверяет фактическое количество и наименование с тем, что написано в накладных.
а кто и когда платит за материал? и что происходит, если прораб написал в заявке одно, а при получении со склада оказалось, что ему выписали совсем другое?
-
при передаче материала на склад прораб принимает материал,т.е. становится материально ответственным лицом.
Предлагаю не забывать про ситуацию когда товар напрямую от поставщика доставляется на строительную площадку минуя склад.
У вас такая ситуация наверняка возможна. По системе как правило оформляют поступление на виртуальный склад, и передачу в производство или перемещение на "производственный склад подрядчика".
-
за материал платит организация-заказчик. т.е. мы. обычно безналичный расчет. но если наличный, то получает обычно менеджер по приемке и платит сам.
обычно на практике опеция "Слад" пропускается. организация пренебрегает таким учетом. и от поставщика сразу материал переходит к подрядчику. но это совсем не правильно.
если рассматривать идеальную ситуацию, то прораб должен получать материал по заявке
-
много нечетких формулировок - можно запутаться. мы ведь пока организацию-заказчика вообще не рассматривали. выходит, что прораб может любую фигню заказать и что с ней будет потом совершенно не очевидно, но заказчик должен будет оплатить. поэтому должен быть контроль со стороны заказчика (либо на худой конец генподрядчика) - у него ведь есть проект и плановая смета/спецификация.
какая организация пренебрегает учетом? исполнитель (тогда это понятно)? ваша (это странно)? заказчик (это глупо)?
если рассматривать идеальную ситуацию, то прораб после принятия заявки в работу должен получать какой-нибудь корешок фактического заказа (своего рода наряд), что бы сразу убедиться в соответствии заявки и реально заказанного. а на основании этого наряда происходит получение материала. при этом при рассмотрении заявки должна производиться сверка со сметой/спецификацией (нужен или не нужен этот материал), с планом работ (пора или не пора использовать материал в работе) ну и тому подобное...
-
давайте разберемся. мы и есть организация-заказчик, которая нанимает подрядную организацию на строительство объекта. у нас есть смета по которой ведется строительство. каждый месяц прораб составляет заявку. мы(как организация-заказчик строительных работ) покупаем этот материал. передаем его подрядчику. но передаем не сразу весь. а по мере поступления. т.е. нужно кирпича 200 шт. сегодня прило 100. передаем 100. потом еще 100. передача происходит по накладной на отпуск материала.
исправила немного "квадратики"
-
немного исправила.
-
несущественное для данного изображения дополнение/поправка: контроль выполняется параллельно оплате/доставке/поступлению
по схеме вроде все понятно. теперь попробуйте детализировать перечисленные бизнес-функции и дополнить документами (детали см выше).
мы и есть организация-заказчик.
аааа, понятно. тогда вопрос контроля несколько упрощается. но странно, что учета нет.
-
поняла. делаю
-
сделала примерную детализацию. застряла на контроле.
а где описывать документы?
-
документы являются либо входом, либо выходом функции (либо и тем и другим одновременно - если в рамках функции что-то в них дополняется)
показать на той же схеме как-нибудь в духе: Входной Документ --> Функция --> Выходной документ
-
докуенты. не уверена
-
дубль два
-
пробежался по детализации - вы все пытаетесь всунуть туда функции будущей системы. пока этого делать не надо! мы ведь описываем бизнес, как он выглядит еще до создания системы, чтобы понять какие функции в системе должны быть, чтобы помочь решению проблемы, возникшей в бизнесе.
На примере заявки попробую пояснить, только не списывайте сразу и напрямую, я ведь мог ошибиться и написать не так как у вас происходит.
- прораб берет чистый бланк заявки (так ведь?) и заполняет позиции нужными ему материалами (как он материалы записывает? есть какие-то коды/номенклатуры? или просто названия?)
- главный инженер строительства подписывает (утверждает) заявку
- прораб несет подписанную заявку снабженцу.
- что происходит с заявкой дальше? может снабженец с ней что-то делает? номер дает? подписывает? подшивает? что?
чтобы было понятно, чем бизнес уровень отличается от реализации в системе попробуйте ответить на следующие вопросы:
- как выглядит каталог поставщиков
- как на основании заявки снабженец ищет в нем нужного поставщика
- как снабженец "создает" поставщика
- как поставщик узнает о заказе
- на основании чего выбирается способ доставки
аналогично про транспортную компанию. кстати, для разных способов доставки должно быть разное наполнение.
- в случае доставки материала поставщиком проверяется или нет количество/качество материалов?
ну и про контроль исполнения заказа тоже что-то должно быть.
-
еще раз
возьмем функцию "формирования заявки". когда она "начинается" никакой заявки нет, потом выполняем функцию ("делаем монтаж") - и заявка появилась. значит заявка является выходом функции. потом, прораб руководствуется чем-то, когда составляет заявку? или просто чешет репу и смотрит в потолок, и потом вписывает что-то там в заявку?
если дальше смотреть, то также она является входом функции "формирование заказа". что еще из документов нужно для того чтобы сформировать заказ? заказ всегда формируется только из одной заявки? что будет выходом?
и так по каждой функции нужно пройти.
-
понятно. пытаюсь сделать
-
доработала детализацию
-
еще файлик
-
надеюсь, правильно Вас поняла.
-
да, по картинке в целом заметно, что появилось некое понимание, есть ряд ошибок, связанных с появлением документов (договор, доверенность) "из ниоткуда", но эти документы могут быть внесистемными (бумажными) и существовать априори - это нужно отдельно оговаривать. несколько смущает, что функция контроля не имеет входящих документов. это неправильно, ведь нельзя контролировать не получая информации.
в общем теперь нужно читать вашу же детализацию и устранять несоответствия процесса и описания, за основу берется описание.
по детализации, кстати, очень даже неплохо. если посмотреть внимательно, то можно даже найти много полезного за что зацепиться (в хорошем смысле) при дальнейшем проектировании системы: папочка, куда подшиваются заявки, папочка с прайс-листами поставщиков (кстати, для нового поставщика его прайс-лист тоже подшивается), папочка с прайсами транспортных компаний (а про подшивание их данных - есть).
оплата материала и оплата доставки, как бы ни были они похожи - это разные вещи. я бы порекомендовал разделить, а второе включить в доставку, т.к. доставка у вас будет по сути отдельной функцией со всеми ее прибамбасами, потому что основной акцент системы - на движение материалов.
только не путайте заявки и заказы. лучше намеренно использовать разные термины. один вопрос так и остался неотвеченным: по одной заявке всегда один заказ на одного поставщика на определенный вид продукции? или все-таки происходит какая-то перекомпоновка заказов для увеличения объема в целях снижения цены?
насчет приемки много вопросов, но не к описанию, а к предметной области. что значит доставлен верно? столько сколько заказывали? или столько сколько в ТТН? конечно корректный учет факта важен, но недостаточен для решаемой задачи, нужно будет ориентироваться на обеспечение соответствия нужному количеству, т.е. становятся существенными некоторые контрольные действия, как у вас написано, по работе с поставщиком и транспортной компанией (кстати, сроки не задерживаются, задерживается поставка, а сроки могут нарушаться). это важно, т.к. они точно должны будут выполняться с помощью системы, помимо очной проверки.
как с проверкой наличия при отпуске со склада?
вообще это описание уже начинает походить на userstory, да поправят меня более сведущие в тонкостях технологии коллеги. впрочем мы сейчас добиваемся некоего понимания с чего начать делать систему и до программирования ессно не дойдем. с этим вы и сама справитесь. зато вы точно будете знать, что должно появиться в системе, а что лишнее - это гораздо важнее. плюс останется довольно много простора для творчества при проектировании системы, чтобы можно было решить "как делать ту или иную функциональность".
что дальше? дальше должна пойти в основном ваша самостоятельная работа. и я и коллеги конечно могли бы много чего еще подсказать при проектировании, но ведь не мы отвечаем за ваш результат.
можно дорабатывать и детализацию (там мелочи остались), и схему процесса (лучше все-таки сделать ее более похожей на процесс, знаете/помните про блок-схемы?), но в целом скоро (не сегодня-завтра) вы можете начать согласовывать с бизнесом предметное содержание задачи. такое оформление бизнес поймет гораздо лучше вашей первой схемы, по крайней мере будет проще объяснить что к чему.
теперь нужно вычленить из детализации (достаточно распечатать и обвести чем-нить) моменты, которые вы точно должны будете сделать в системе. вы это должны знать из:
- исходно поставленной задачи
- понимания предметной области, важности тех или иных элементов, сущностей, операций.
- понимания каких-то особенности и исходя из удобства работы (в смысле решения задачи, стоящей перед ними)будущих пользователей.
из этого нужно будет сделать usecases системы. потом продумать поведение (что будет после того как пользователь сделает то-то), роли пользователей тоже нужно продумать
нужно придумать как будет "выглядеть" система: с какими формами будут работать пользователи. и тд и тп.
и не нужно хвататься за все сразу и "засовывать" в систему все ваше описание. определите ядро и сделайте его. остальное добавите позже. лучше получить компактную (пусть даже неполную во второстепенных функциях) и работающую систему, чем сделать огромную и рыхлую хрень, с которой только проблемы.
из всего этого рождаются требования к системе. а дальше реализация. по использованию uml для создания системы могу посоветовать книжку Крэга Лармана (она и в магазинах должна быть, и в интернете есть), неоднократно здесь упоминавшуюся. почитайте также тему по usecase, которая много обсуждалась в последнее время.
ну и приходите-показывайте промежуточные результаты и если будут вопросы тоже милости просим. главное вы будьте уверены в своих силах, судя по всему с техникой у вас все будет хорошо... через некоторое время, хоть вы и оцениваете себя как не очень хорошего программиста :о)))
думаю, что первый урок вполне успешно окончен :о)))
-
Вы невероятную помощь мне оказываете! спасибо Вам огромное!
если Вас не затруднит, то я буду выкладывать свои результаты.
Спасибо еще раз!
-
к сожалению, из-за неравномерной нагрузки я далеко не всегда смогу помочь. но может коллеги поддержат. в крайнем случае можно в личку написать, но без гарантий по скорости ответа.
с другой стороны, вы вроде тоже схватываете с довольно приличной скоростью. на самом деле я практически ничего не сделал (кроме набивания сообщений) - все что было сделано, сделали вы сами. ну а ошибки и неточности - куда от них деваться? их надо пройти.
вам нужно только научиться не тонуть в деталях и правильно понимать и видеть перспективу (своего рода последовательность работы). реальное знание предметной области (а оно у вас есть, как вы и писали вначале) вам сильно поможет. в принципе не стесняйтесь спрашивать у бизнеса варианты, наблюдать за приемами работы будущих пользователей уже сейчас, но не полагайтесь только на них. предлагайте/формулируйте что-то вроде "предлагаю в качестве основного способа работы в таком-то режиме такую-то последовательность действий", они ведь явно или неявно ожидают от вас этого: вы в этом специалист, вот вы и предлагайте. пользуйтесь этим. но и анализируйте возможные последствия - этому придется научиться на своем примере - и выбирайте оптимальный для данных условий вариант с небольшим заглядыванием вперед. аналогично и с разработчиками (даже если один из них вы сами).