116
« : 21 Апреля 2011, 20:50:49 »
да, по картинке в целом заметно, что появилось некое понимание, есть ряд ошибок, связанных с появлением документов (договор, доверенность) "из ниоткуда", но эти документы могут быть внесистемными (бумажными) и существовать априори - это нужно отдельно оговаривать. несколько смущает, что функция контроля не имеет входящих документов. это неправильно, ведь нельзя контролировать не получая информации.
в общем теперь нужно читать вашу же детализацию и устранять несоответствия процесса и описания, за основу берется описание.
по детализации, кстати, очень даже неплохо. если посмотреть внимательно, то можно даже найти много полезного за что зацепиться (в хорошем смысле) при дальнейшем проектировании системы: папочка, куда подшиваются заявки, папочка с прайс-листами поставщиков (кстати, для нового поставщика его прайс-лист тоже подшивается), папочка с прайсами транспортных компаний (а про подшивание их данных - есть).
оплата материала и оплата доставки, как бы ни были они похожи - это разные вещи. я бы порекомендовал разделить, а второе включить в доставку, т.к. доставка у вас будет по сути отдельной функцией со всеми ее прибамбасами, потому что основной акцент системы - на движение материалов.
только не путайте заявки и заказы. лучше намеренно использовать разные термины. один вопрос так и остался неотвеченным: по одной заявке всегда один заказ на одного поставщика на определенный вид продукции? или все-таки происходит какая-то перекомпоновка заказов для увеличения объема в целях снижения цены?
насчет приемки много вопросов, но не к описанию, а к предметной области. что значит доставлен верно? столько сколько заказывали? или столько сколько в ТТН? конечно корректный учет факта важен, но недостаточен для решаемой задачи, нужно будет ориентироваться на обеспечение соответствия нужному количеству, т.е. становятся существенными некоторые контрольные действия, как у вас написано, по работе с поставщиком и транспортной компанией (кстати, сроки не задерживаются, задерживается поставка, а сроки могут нарушаться). это важно, т.к. они точно должны будут выполняться с помощью системы, помимо очной проверки.
как с проверкой наличия при отпуске со склада?
вообще это описание уже начинает походить на userstory, да поправят меня более сведущие в тонкостях технологии коллеги. впрочем мы сейчас добиваемся некоего понимания с чего начать делать систему и до программирования ессно не дойдем. с этим вы и сама справитесь. зато вы точно будете знать, что должно появиться в системе, а что лишнее - это гораздо важнее. плюс останется довольно много простора для творчества при проектировании системы, чтобы можно было решить "как делать ту или иную функциональность".
что дальше? дальше должна пойти в основном ваша самостоятельная работа. и я и коллеги конечно могли бы много чего еще подсказать при проектировании, но ведь не мы отвечаем за ваш результат.
можно дорабатывать и детализацию (там мелочи остались), и схему процесса (лучше все-таки сделать ее более похожей на процесс, знаете/помните про блок-схемы?), но в целом скоро (не сегодня-завтра) вы можете начать согласовывать с бизнесом предметное содержание задачи. такое оформление бизнес поймет гораздо лучше вашей первой схемы, по крайней мере будет проще объяснить что к чему.
теперь нужно вычленить из детализации (достаточно распечатать и обвести чем-нить) моменты, которые вы точно должны будете сделать в системе. вы это должны знать из:
- исходно поставленной задачи
- понимания предметной области, важности тех или иных элементов, сущностей, операций.
- понимания каких-то особенности и исходя из удобства работы (в смысле решения задачи, стоящей перед ними)будущих пользователей.
из этого нужно будет сделать usecases системы. потом продумать поведение (что будет после того как пользователь сделает то-то), роли пользователей тоже нужно продумать
нужно придумать как будет "выглядеть" система: с какими формами будут работать пользователи. и тд и тп.
и не нужно хвататься за все сразу и "засовывать" в систему все ваше описание. определите ядро и сделайте его. остальное добавите позже. лучше получить компактную (пусть даже неполную во второстепенных функциях) и работающую систему, чем сделать огромную и рыхлую хрень, с которой только проблемы.
из всего этого рождаются требования к системе. а дальше реализация. по использованию uml для создания системы могу посоветовать книжку Крэга Лармана (она и в магазинах должна быть, и в интернете есть), неоднократно здесь упоминавшуюся. почитайте также тему по usecase, которая много обсуждалась в последнее время.
ну и приходите-показывайте промежуточные результаты и если будут вопросы тоже милости просим. главное вы будьте уверены в своих силах, судя по всему с техникой у вас все будет хорошо... через некоторое время, хоть вы и оцениваете себя как не очень хорошего программиста :о)))
думаю, что первый урок вполне успешно окончен :о)))
Просмотр сообщений
