ссылки на ГОСТы
ГОСТы на АСУ 70-90-х годов полезно почитать для общего развития. В содержательной части (что должно быть предусмотрено при разработке АСУ) они весьма толковые, но в методологической части (управления проектом, структуры документации и программно-аппаратной инфраструктуры) они, очевидно, сильно устарели и поэтому требуют творческого переосмысления.
Вот например думал попробовать реализовать систему учёта продукции магазина, продажи/завоз/наличие товара на складе, вывод отчётов и пр. но увы своей фантазии не хватит для того, чтобы сделать всё "по правилам" и учесть все аспекты требуемые реальному предприятию/фирме для работы. Думал что в ТЗ всё расписывают до мелочей, но теперь понимаю что нет =\ надо в другом направлении копать
Любая система из того класса, который тебя интересует - это в первую очередь многоуровневый анализ требований, в котором технические решения (собственно проектирование программ и программирование) подчиняются управленческим решениям. Подчинение принимаемых решений и выбираемых стратегий на более низких уровнях требованиям и ограничениям более высоких уровней называется трассировкой. Грубо говоря, если в приложении есть какая фича или просто кнопочка - всегда должны быть понятны те требования, для выполнения которых программист эту фичу или кнопочку придумал. В программной системе нет случайных и лишних вещей.
В частности, в ГОСТе упомянуты: математическое, информационное, лингвистическое, программномное, техническое, метрологическое, организационное, методическое и пр. виды обеспечения системы. Как видишь, собственно программирование - это весьма малая часть АСУ. АСУ - это ещё и перестройка работы предприятия. Например, твоя программа учёта должна быть внедрена: нужно определить пользователей, для пользователей нужны основания (распоряжения руководства) для работы с системой, пользователям нужны ресурсы (их время, техника и т.д.), нужно обучение пользоваталей и много чего ещё.
При всём том довольно часто само руководство, инициирующее такой проект, не осознаёт всех аспектов влияния внедряемой АСУ на работу вверенного им предприятия и необходимых затрат - не только прямых (оплата работы программистов), но и косвенных (реорганизация деятельности предприятия). Я лично адекватных руководителей видел только на крупных предприятиях (в структурах бывшего РАО ЕЭС, на предприятях Силовых машин). Конечно, для одного магазина (не сети) всё более неформально и потому дешевле, но, тем не менее, всесторонность и системность в работе всё равно необходима. И только на уровне отдельного ларька с парой сменных продавцов можно сразу кинуться в программирование.
Борьба с обилием мелочей осуществляется за счёт многоуровневости. На высоких уровнях требования и ограничения формируются настолько обобщённо, что у разработчиков остаётся свобода действий на более низких уровнях. Кроме того, на более низких уровнях обычно выявляется какая-то системная структура, которая позволяет вести разработку по независимым частям - выделяются независимые функции (задачи) системы, что на уровне программного кода превращается в инкапсулированные модули.
Я лично для себя выделяю трёхуровневую матрицу вопросов "зачем?" "что?" и "как?". И эта матрица упорядочивает все уровни требований и принимаемых решений.
Например, применительно к твоей системе можно задать вопрос "зачем (она нужна)?" Наверно, ответ на этот вопрос будет достаточно короткий. Что-то в духе: "Мы хотим попробовать уменьшить нашу дебиторскую (и, возможно, кредиторскую) задолженность, складские запасы, долю списываемого просроченного товара и т.д." Такая довольно очевидная для кризисных времён проблема. Следующий вопрос "что (система должна делать)?". И, возможно, он будет выглядеть как: "Для этого мы хотим реорганизовать и автоматизировать учёт движения товаров, чтобы повысить оперативность информирования руководства магазина о товарном обороте. Это позволит более своевременно и точно принимать решения по взаимодействую с поставщиками и проведению маркетинговых акций (реклама, скидки, распродажи и т.п.)" Следующий вопрос: "как (система должна реорганизовать и автоматизировать учёт)?" Ответ обычно состоит из 2-х частей: описания "как оно есть сейчас" и описания "как оно должно быть" - тут могут быть самые разные истории про то, что из нашего 1С-решения нельзя получить такие-то агрегированные данные, нужные для принятия управленческих решений, или про то, что приёмка товаров на складе проводится не так, как хотелось бы и т.д.
Нередко все описанные проблемы решаются не внедрением программной системы, а банальным устранением бардака и повышением исполнительской дисциплины. Но, допустим, заказчика не устраивает учёт в какой-нибудь типовой конфигурации 1С.
Сдвигаемся на уровень ниже. В нём уже есть ответы на вопросы "зачем?" (чтобы реогранизовать и автоматизировать учёт) и "что?" (нужны отчёты с такими-то агрегированными данными, но 1С их не предоставляет). Возникает следующий вопрос: "как (эти отчёты получить?)" Тут тоже масса вариантов: и модификация конфигурации 1С (с последующей проблемой обновлений), и разработка собственной системы, интегрированной с 1С, которая либо вводит недостающие в 1С данные, а отчёты строит по данным из 1С и их своей БД (этот вариант очевидно неудобен для ручного ввода в 2 программы), либо предоставляет свой интерфейс для ввода всех данных, и часть из них сама копирует в 1С. Тут же определяются пользователи системы (с каких рабочих мест вручную или из каких других программных решений путём экспорта/импорта в разрабатываемую систему будут поступать данные). Структуры данных и содержание отчётов можно наметить, но, как правило, со временем у заказчика появляются новые "хотелки". Это значит, что основной задачей на этом уровне является не разработка форм отчётов и ввода данных (это ещё рано) разработка технологии получения, хранения и обработки данных в условиях оговоренной аппаратно-программной инфраструктуры (ОС, уже эксплуатируемые АСУ и прочие информационные системы, какие-нибудь там POS-терминалы, СУБД и т.д.) Того, что называется системной архитектурой.
Так проводится анализ и сбор требований, которые формируют собственно ТЗ. На каждом уровне можно остановиться и зафиксировать соглашения. Каждый следующий уровень добавляет новые принятые решения и уменьшает энтропию системы (пространство для манёвра разработчика). Тут очень важно не уменьшить энтропию сразу. Когда в ответ на "Мы хотим попробовать уменьшить нашу дебиторскую (и, возможно, кредиторскую) задолженность, складские запасы, долю списываемого просроченного товара и т.д." сразу говорят: "Ща мы вам напишем программу на C++ и SQL Server - она решит все ваши проблемы". Очевидно, что непрофессиональный и (по здравому рассуждению) нелогичный подход, поскольку совершенно не ясно, как SQL Server связан со складскими запасами, и нужен ли он вообще для более эффективного управления ими.
Те ответы на вопросы зачем, что и как, которые я выше написал - это грамотные ответы. Их можно и в книжках прочитать, когда там разные примеры разбирают. Но в 99% случаев руководители предприятий не являются бизнес-аналитиками. Это значит, что такие ответы руководители не дадут. Если они (начитавших интернетов и посоветовавшись с друзьями) начинают рассуждать про базы данных, программы и говорить, что эти программы должны делать - это всё можно записать, но скорее всего оно либо не пригодится вовсе, либо пригодится в неполном виде. Поскольку за всем этим нет ответов на вопросы "зачем?" и "что?" Руководители сразу переходят к ответу "как (оно им видится)", считая, что плоды их размышлений над проблемой - либо их личное дело, либо и так всё очевидно. Как правило, это привычка руководителей решать единолично и, не откладывая в долгий ящик, сразу переходить к делу (особенно сильна у мелких предпринимателей, неискушённых в аппаратной работе в бюрократической среде); при этом разработчика такой руководитель рассматривает в роли такого же исполнителя его замыслов, как и своих сотрудников.
Казалось бы: ну раз он придумал, то взять и сделать, как он хочет; и кнопочки покрасить в зелёный цвет, раз ему так припёрло - пусть порадуется. Подход в корне неверный. Потому что больше всего такому руководителю хочется решить проблему, а не написать программу (что хочется разработчику). Если в процессе разработки или внедрения такой руководитель обнаружит, что деньги он потратил, а проблема осталась нерешённой - он будет очень недоволен. Но недоволен не собой, а тем непрофессиональным разработчиком, который не смог удовлетворить его "хотелки" - никто не любит брать ответственность за неудачи на себя. Вплоть до того, что работа не будет принята и деньги за разработку не будут выплачены. Чтобы застраховаться, разработчик заключает договор и может выбить деньги по формальным основаниям, но "осадочек" останется у всех участников проекта. У разработчика подход в духе "чего изволите?" работает только в случае крайне низких издержек, когда заказчик начинает экспериментировать и "баловаться" разными подходами к решению проблемы (а то и судорожно метаться в поисках правильного решения), а разработчик ему в кратчайшие сроки поставляет новые версии с его новыми "хотелками", и при этом берёт мало денег. Разработка любой сложной системы - дорогое удовольствие, и концептуальные ошибки дорого стоят не только заказчику, но и разработчику в части его репутации на рынке.
Поэтому реальную проблему, которую должна решить система, нужно из руководителя выуживать из под шелухи его придумок. Проблему он знает, но обращается к разработчикам уже после "Я тут думал-думал и придумал вот что: ..." И при этом разговор надо вести аккуратно - так, чтобы у такого руководителя не возникало ощущения, что эти молодчики-консультанты тут за него начнут распоряжаться на его предприятии, или что его собственные задумки - форменная глупость, а сам он - полный дурак. Как говорится: "Входить к начальнику нужно со своим мнением, а выходить - с мнением начальника."
