Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Между ТЗ и SRS есть много отличного. Начнем хотя бы с того, что ТЗ есть по ГОСТ 34 и 19.
сказали, позвонят. но такого ужасного собеседования у меня никогда не было.
откровенно, HR пыталась унизить и оскорбить. показать какой крок опупенный, что работать там честь
Юра, а почему на твой взгляд это не используется? Какова альтернатива и в чем ее преимущество?
Да и что подразумевается в данном случает по внедрением?
У каждого из тех, кто долго работает в какой-то сфере, вырабатываются свои приемы и стиль.
Я, например, давно не пишу документов, а думаю в терминах модели. И пишу шаблоны генератора отчетов (редко, т.к. наработал структуры моделей и шаблоны для них).
Мне легче рисовать на UML, чем писать, даже во время интервью.
Из одной общей модели можно "нагенерить" множество отчетов самого разного вида, размера и содержания.
А "государственными заказчиками" и ГОСТами, на мой взгляд, пугать не нужно.
1. Там люди. Если эти люди хотят получить хороший продукт, они с пониманием относятся к технологиям. Если им нужен "откат", никакие ГОСТы не помогут.
2. Из хорошей полной модели вполне можно создать "ТЗ-подобный" отчет простым использованием синонимов, соответстующих терминологии ГОСТов.
3. Плюс массу документов для разработчиков.
Ты, Юра, редко доходил до "сторибоарда"? А зря!
Спецификация прецедента на основе диаграммы деятельности (полезная при согласовании требований), при небольшом расширении шаблона может стать "сторибоардом" для разработчика, "тесткейзом" для тестировщика и "руководством пользователя".
И все они актуальны и синхронны.
Производительность труда группы в целом повышается.
да, но можно поподробнее?
Мне очень нравится сайт uml2.ru . Я считаю его одним из самых полезных, а участников - корректными, адекватными и говорящими по делу в большинстве своих постов.
Кроме того, системный анализ - область со своей сложной терминологией, требующая также применения терминов из логики, математики, философии. Да и каждая предметная область обладает собственной терминологией, зачастую тоже зубодробительной.
Но всё же случается, что участники применяют сложные термины, расхожие выражения, "туманные" слова, англицизмы и неологизмы и другие "баззворды" не к месту, или просто слишком часто.
Чтобы участники этим не злоупотребляли - предлагаю реализовать на постах форума "bullshit bingo". Это такой режим, который участник может включить у себя в профиле. И после того, как включил:
1) "баззворды" у него начинают подсвечивается;
2) каждые, например, 10 "баззвордов" в ветке, которую смотрит участник, начинает отображаться пост "Бинго!".
Предположение о реализации - пре-процессинг записей, извлекаемых из БД, при формировании страниц форума.
Подробнее:
http://en.wikipedia.org/wiki/Bullshit_bingo
http://netlore.ru/Bullshit_Bingo
http://e-loto.altsoph.ru/
Чтобы сформировать список "баззвордов", каждый участник может запостить в эту ветку несколько "баззвордов", в употреблении которых заметил других и особенно себя.
не настолько отдельный. и юзкейсы есть, и ТЗ, а на бизнес-процессах как раз все построено. тонкость в том, что в готовой системе уже есть некоторая реализация всего этого, референтные модели, то, сё. но принципиально всё то же самое. разве что иногда все-таки имеются наработки/заготовки, обкатанные в других проектах. но дело в том, что с заказчиками обычно такая история, что они говорят, дескать, нам ничего менять не надо, только вот тут чуть-чуть подправить .... и на-ча-лось...
...
По поводу выбора клиента из комбика.
Типичная ошибка начинающего программера. Я понимаю проект учебный, но
если у вас будет много, очень много клиентов. Ну не меньше несколько сотен, Вы их тоже все будете загонять в комбик? А сам список как формируете, вероятно прямо на браузер клиента портируете весь список чухом?
Хорошо если вы продумали такое поведение датасета, при котором происходит подгрузка данных по мере движения в комбике
А "для работы" Вы use cases моделируете? На каком инструменте?
Идите стажером, вакансии есть, например: http://moikrug.ru/feed/756429963/
Можете связаться со мной или с Дмитрием.
Всем спасибо за информацию, буду пытаться применить на практике
Я объясню, в чем основная сложность с документацией.
У заказчика очень тяжелый, затянутый процесс согласования документов. К моменту официального согласования может пройти столько времени, сколько требовалось на разработку половины системы - поэтому дожидаться этого момента мы не можем. Это идиотизм, но в таком режиме все равно приходится работать.
Неактуальность имеющейся документации (а точнее - отсутствие достоверной информации о том, как система устроена) приводит к тому, что при разработке и тестировании мы спрашиваем друг у друга "а как правильно?" - т.к. далеко не всегда можно найти правильный ответ в ТЗ и далеко не всегда на эти вопросы готов ответить заказчик.
Система была написана на коленке, теперь ее предстоит модернизировать, добавить много нового функционала и переписать существующий, т.к. в своем теперешнем виде она мало пригодна для дальнейшего развития. Вот для того, чтобы понять, как развивать, нужно понять, как есть сейчас.
а почему именно в банк?
