Программное обеспечение в бизнесе

Gustaf,

Практика, замечу, бывает очень разная. Если в своей "практике" вам не доводилось программировать\поддерживать системы реализующие описанный функционал, то это не означает что таких систем не существуют в природе. Не расстраивайтесь, все бывает когда-то в первый раз ... ну или не бывает вообще

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

Попробуйте подойти системно и в своей предметной области для себя глобально выделить (нарисовать на бумаге):

- объекты автоматизации

- их характеристики (свойства)

- требуемые действия над объектами автоматизации

переведите эти три пункта на язык человека, никогда не сталкивавшегося с программированием. Что например такое- обьекты автоматизации? Это компьютер? Это бухгалтер Машенька? Это журнал учета? Это магазин?

Какие есть характеристики у Маши? У магазина? У журнала учета? Ну Машины характеристики то понятны, и требуемые действия над ней тоже, если с характеристиками все в норме. А если это старая 60-летняя МарьяИванновна? Где взять на нее характеристики? В отделе кадров?

Как выглядят "требуемые действия" над журналом учета? Достать с полки, положить на полку?

- требуемые выходные формы\отчеты после выполненных действий над объектами

выходные отчеты после действия "закрыть" над обьектом "магазин" какие? Поставить на сигнализацию? Но мы пока не хотим заходить так далеко...

Дальше определите:

- количество пользователей\ролей в вашей системе

Что еще за роли? У нас не театр, у нас работают...

- необходимость в сетевом доступе к БД ПО (через локальную сеть, через интернет и т.п.)

Не блин, к бд сетевого дотупа не надо, будем использовать голубиную почту. И вообще у нас вайфай, так что никаких сетей.

- необходимость в авторизованном доступе к БД (через логин и пароль)

еще раз - у нас вайфай, поэтому доступ надо сделать не через логин и пароль, а через вайфай

- объем операций\сделок\транзакций в день

ну, обьемы у нас в литрах, транзакции у нас в банке, а сделки бывают разные, тут как повезет. Что определять?

- необходимость функции поиска в системе

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

- необходимость ведения историчности данных

историчности или истеричности? Первое не надо, у нас не музей, со вторым хорошо справляется наш главбух

- необходимость протоколирования действий пользователей системы

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

- необходимость разграничения по ролям право на выполнение определенных операций\просмотр данных

разграничить чего куда зачем?

Если в своей "практике" вам не доводилось программировать\поддерживать системы реализующие описанный функционал, то это не означает что таких систем не существуют в природе.

такие системы существуют. Точнее не существует систем, в той или иной мере не поддерживающих "описанный функционал". Уж точно "обьекты" с "характеристиками" есть наверное везде.

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

Только, наверное, наш программист ( и швец, и жрец и на дуде игрец) знает лучше заказчика "что именно ему надо" (а не наоборот) и будет его учить как именно ему вести свой учет. 5 баллов!

Не поверите, но это именно так. Заказчик мыслит категориями предметной области, причем категориями во многом неформализванными. А ваша задача - все разложить по полкам, убрать неоднозначности, и даже предвидеть будущие запросы. Если опыта нет - все это придется делать уже в процессе разработки, а не до. С переделками, с поломками, с багами.

Def, просто такие вопросы надо задавать только CIO (Chief Information Officer). Приходите к клиенту и говорите - у вас есть CIO на фирме. Если говорит нет - посылаете нафиг. Мы с такими тупыми неорганизованными клиентами, у которых даже нету CIO работать не будем.

Def, Пишете редкую муйню. Хотели, видимо, блеснуть умом, но, как всегда, ничего не вышло.

А Gustaf действительно написал достаточно грамотно и если человек на понимает, что там написано,то ему лучше попросить пройтись по-этим пунктам того, кто понимает и заплатить ему.

Gustaf,

Попробуйте подойти системно и в своей предметной области для себя глобально выделить (нарисовать на бумаге):

- объекты автоматизации

- их характеристики (свойства)

- требуемые действия над объектами автоматизации

- требуемые выходные формы\отчеты после выполненных действий над объектами

Дальше определите:

- количество пользователей\ролей в вашей системе

- необходимость в сетевом доступе к БД ПО (через локальную сеть, через интернет и т.п.)

- необходимость в авторизованном доступе к БД (через логин и пароль)

- объем операций\сделок\транзакций в день

- необходимость функции поиска в системе

- необходимость ведения историчности данных

- необходимость протоколирования действий пользователей системы

- необходимость разграничения по ролям право на выполнение определенных операций\просмотр данных

Ну нет. Так только салаги делают. Настоящий профи поступает совершенно иначе. Он уверенно заходит в компанию и, глядя в упор на присутствующих, громко спрашивает - Кто у вас тут CEO и уполномочен вести переговоры? Когда СЕО неосмотрительно выходит, надо взять его за верхнюю пуговицу пиджака и, слегка её покручивая, спокойным тоном довести:

- В глаза смотреть сева! Ну так вот, с-сева... Проделаешь мне полную декомпозицию объектов своей предметной области и пришлёшь к утру на почту в виде UML. Базу данных нарисуешь в виде IDEF1X. И смотри, с-сева, что бы не ниже третьей нормальной формы была. Ты меня понял, сева? Ну и ладушки. Иди работай, не теряй время. Ото нам ещё всю эту мутотень автоматизировать.

PS: Поддерживаю Defа,

Crush,

Блин, ну не надо гнать на товарища Gustaf'а.

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

Просто товарисч Gustaf немного оторвался от реальности, и наверное не в курсе, что у беларуских фирм-заказчиков ПО очень трудно со штатными аналитиками, более того, даже импортные фирмы очень редко имеют такого.

Совершенно очевидно что товарисч Gustaf прочел умную книжку, и теоритически знает как это просто - снять задачу у заказчика и проследить чтобы "тупые кодеры" правильно сделали "необходимость ведения историчности данных", но к сожалению он не попробывал еще свои знания на практике.

Когда перед товарисчем Gustaf-ом посадят заказчика, который на ломанном английском начнет обьяснять товарисчу Gustaf-у основные принципы страховых выплат в штате Миссисипи, или пытаться донести до него динамические характеристики плейтера и особенности химических реакций, вот тогда и посмотрим, как он будет из этого бреда выделять "требуемые действия над объектами автоматизации".

StudentBNTU,

Def, Crush, Ребезята, о чем базар.

Вы работаете в очень серьезных компаниях, вопросов нет. Ваши продукты акуенно крутые, оптимизированные настолько, что превращают Пентиум-1 в современный компьютер, etc. Вы сами мега-гуру в IT, все остальные соски.

т.е. вы в принципе согласны с моим описанием вашей фирмы?

Yosic,

Проблема в том, что это не работа товарища Gustaf'а, и поэтому он 100% прав. Не можете предоставить нормальное ТЗ - нету работы. И если специфика заказчиков такова, что они на 90% такие, то организация просто держит своих специалистов по-составления ТЗ и включает их работы(даже на гласно) в конечную стоимость. Все просто. Ну, а вы ведете разговор с позиции одиночки, но тут уж или бери заказ и делай все сам либо не бери.

Проблема в том что есть еще разнообразные варианты работы без ТЗ. И для работы в одиночку, и для работы тимом. И даже для работы фирмой. К сожалению формат ветки и лень не позволяет мне вас просветить, поэтому вам придется обходиться вариантом "нет ТЗ - нет работы"

Проблема в том, что это не работа товарища Gustaf'а

а чего это вы вообще за товарисча Gustaf'а отвечаете? Может это как раз его работа. Вы знакомы?

Когда токарь точит деталь ему дают чертеж или ему проектировщик на пальцах объясняет, что он должен получить?

Тут та же ситуация.

т.е. мы гордого программера низводим до тупого кодера?

Gonzalos,

т.е. мы гордого программера низводим до тупого кодера?

Опять хотим с ног на голову поставить все. Задача программиста не узнавать, что хочет заказчик, а правильно и максимально эффективно это реализовать.

То есть работать с ТЗ(чертеж для токаря). Так называемый кодер выполняет реализацию стандартных задач, читай токарь точит одну и туже деталь или группу деталей которые он знает как точить.

StudentBNTU, Рад, что кому-то помог