Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Леонид

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 »
151
Что касается пользы от специализированных инструментов, то она сомнительна.

Аминь.

Дюжину лет назад тестировщики моего отдела достаточно свободно работали со схемой БД склеенной из 20 листов А4. Это примерно 150-200 таблиц. Про программистов и говорить нечего. Они ее читали "на лету".

Такая работа вполне доступна здравому уму человека. Но заставить так работать сложно.

Я прочитал это так: "Для меня, Леонида, работа с такими диаграммами не представляет труда, для программистов представляет."

Правильнее будет "не представляет сложности, требует только заметного количества труда"

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

Как и больших документов.

152
7. Какие документы ГОСТ 34 являются самыми важными?

С какой точки зрения? Если с формальной точки зрения (получения денег за выполненные работы) - то связка ТЗ + Программа и методика испытаний + отчасти протокол испытаний. Это самые попоприкрывательные документы, при разработке и "реализации" которых требуется максимум внимания.

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

8. Какие документы из ГОСТ 34 являются самыми полезными?

Затрудняюсь ответить. Все хороши для той или иной цели. Если зайти с обратной стороны, мне ни разу не пригодился документ В3."Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы".

9. Что нужно изучить, прежде чем браться за разработку ТЗ по ГОСТ 34?

В первую очередь - эскизное и техническое проектирование и программу и методику испытаний. Причем не теоретически, а на личном опыте. Разработка ТЗ в ГОСТ 34, на мой взгляд, есть высший пилотаж, за который следует браться после освоения всего остального. Ибо буквально каждое слово способно сильно повлиять на проект в целом. Особенно неосторожное слово.
Но понятно, что все это мечты. В реальности с ТЗ у нас начинают знакомство с ГОСТ 34 (и именно поэтому зачастую и заканчивают).

10. Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?

Я этой классификацией (именно как классификацией) не пользуюсь, можно ее в студию? Чтобы я ничего не напутал, просто погуглив.

11. Обязательно ли заполнять все разделы ТЗ, перечисленные  в ГОСТ 34?

Общий ответ - нет, не обязательно. Об этом нам прямо говорит п.2.2 ГОСТ 34.602
Однако нередки случаи, когда приемку со стороны заказчика осуществляют упоротые "законники". Или есть риск, что таковые будут проверять им принятое. В таких случаях рекомендуется ненужные разделы заполнять фразой а-ля "требования не предъявляются".

12. Какие ошибки чаще всего совершают аналитики, использующие ГОСТ 34?

Я в растерянности. Меня только что попросили рассказать самые смешные анекдоты, которые я знаю. А в голову ничего не идет, хоть тресни.

Ну, например, из любимого. Каждый второй путается с "объектом автоматизации". Немудрено, поскольку явного определения, что это такое, ГОСТ 34 не содержит. Отсюда у многих получается, что объект автоматизации - это процессы, которые надлежит автоматизировать.
Однако, если посмотреть внимательнее, можно заметить:
а) в том же ТЗ "3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;"
б) в Пояснительной записке "7) решения по комплексу технических средств, его размещению на объекте;" или "4) мероприятия по изменению объекта автоматизации;"
в) в Общем описании системы "4) описание взаимосвязей АС с подразделениями объекта автоматизации."

Помятую о том, что АС - это не только ПО, но также и ИТ-инфраструктура, которая должна быть где-то развернута, и люди, которые должны быть где-то рассажены, напрашивается единственный вывод:

Объект автоматизации - это ГДЕ происходит автоматизация.

Чаще всего объект автоматизации представляют в одном из двух вариантов (или их комбинацией):
а) Перечень орг.подразделений заказчика: "в подразделениях, ведущих архивную работу"
б) Перечень адресов: "в здании Мособл... по адресу г.Москва, ул...,"



153
Однако у меня все ходы записаны. :) Вопросы есть, ответов только нет.

Ну, тогда на правах свирепого оффтопа... (может, перенесет кто куда надо?)

1. Является ли ГОСТ методологией разработки?

Зависит от того, как определить "методологию". Мое мнение - да, является. Рамочной. Поскольку определяет:
1. Что должно быть сделано.
2. В какой последовательности.
3. Как должно сдаваться.
4. Как должны выстраиваться формальные отношения между сторонами разработки.

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

2. Когда следует применять ГОСТ 34?
Когда:
а) это прямо предписано контрактом,
б) нужно подстелить соломки ввиду невнятных перспектив проекта,
в) умеете это делать,
г) в иных случаях.

3. Когда не следует применять ГОСТ 34

В целом - не следует, когда без него получается лучше, чем с ним.

Например, относительным противопоказанием применения ГОСТ 34 являются проекты итерационного характера. Но не все, а те, для которых характерно появление совершенно новых требований от итерации к итерации (не то, что нельзя, а просто сильно неудобно).

4. В каких случаях ГОСТ 34 обязателен к исполнению?

См. п.2.а.
Также он становится обязательным, если в документе уровня ТЗ прописали нечто вроде "документы должны быть разработаны с применением ГОСТ 34".

5. На каких этапах жизненного цикла разрабатываются требования по ГОСТ 34?

О каких именно требованиях идет речь? Если в широкой трактовке, то на всех.

С 1 по 6 стадии по ГОСТ 34.601-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ" - достаточно очевидно.
http://rugost.com/index.php?option=com_content&view=article&id=95:gost-34-601-90-avtomatizirovannye-sistemy-stadii-sozdaniya&catid=22&Itemid=53

На 7 стадии:
7.6. Проведение предварительных испытаний.
7.7. Проведение опытной эксплуатации.
7.8. Проведение приёмочных испытаний,
могут возникнуть требования, которые необходимо реализовать в системе или документации для ее приемки.

На последней стадии "Сопровождение АС" появляются требования на последующее развитие.

6. В каких документах по ГОСТ 34 содержатся требования?

Опять же, какие требования?
Если "вообще", то во всех, за исключением оформительских (ведомости технического проекта, например).
а) В предпроектных документах, как правило, требования бизнес-уровня (назначение системы, цели и задачи). С ТЗ и так понятно, там требования - существенная часть.
б)  В документах эскизного и технического проекта - требования к реализации (т.е. чем и как АС будет достигать поставленных в предыдущих документах целей). В том числе, требования к заказчику - что он должен сделать, чтобы все это могло взлететь.
в) В рабочей документации требования к развертыванию. Что куда поставить, что с чем соединить. Как проверить работоспособность.
г) Эксплуатационная документация (части рабочей) суть требования, как и кому следует эксплуатировать систему и что делать "в случае чего".


154
Сталкивались ли вы с такой проблемой?

Часто.

и как бы вы обеспечивали согласованность жизненных циклов сущностей?

Обеспечивали по первому варианту. Поскольку практически всегда по отпочкованным сущностям нужен свой учет, а организовать под это дело вычленялку Б из В непросто (когда вообще возможно) и недешево с точки зрения вычислительных мощностей.

Не исключаю ситуаций, в которых более интересным окажется вариант 2. Однако это бомба под дальнейшее развитие.

155
А вот это предлагаю внести в методические рекомендации по использованию ГОСТ от <придумайте от кого>:

Да вроде нет у нас таких. Была тема, в которой собирались сформировать ЧАВО, да так и не собрались, помнится.

Не рекомендуется включать ВИ в ТЗ по ГОСТ 34. ... и 19. ...

Совершенно верно. Неоднократно в разных темах обсуждалось.

156
1. Если вы вынуждены использовать ТЗ как контракт, то постарайтесь не писать туда требования третьего уровня. Пишите второго уровня и как можно более высокого. Кстати. Показывать это ТЗ программистам совершенно необязательно.
2. Для программистов лучше писать на третьем уровне.

Об этом же, кстати, ГОСТ 34.

157
На уровне слайда такую схему хорошо делать, если вы собираетесь кому-то что-то втюхать. Ибо для "улучшения" восприятия, вы уберете все неприятные моменты.

Да, если цель втюхать. Или нет, если цель противоположная - попытаться отговорить от опрометчивого шага.

Для анализа нужно работать с полной схемой. И проблема тут не в том, что она нечитаема. Читаема, просто времени нужно несколько больше.

Теоретически - соглашусь. Более-менее грамотно отрисованное вполне можно читать, было бы время. Но практически, схемы из 200+ элементов и 500+ связей не читают даже те технари, для которых они предназначены. Проверял на моделях БД неоднократно. Пугается такого клубка человек, и уходит в оборону.

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

Проблема в отрицательной обратной связи в нашей индустрии. За нахождение ошибок в таких схемах "тестировщику" создавали неприемлемые условия и он уходил. Теперь никто такие схемы не анализирует.

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

Итог: "Даже если вам повезет, и среди тысячи сотрудников вашей фирмы найдется кто-то, способный такую схему нарисовать, то прочитать ее будет некому.

Так точно. Ибо никто не хочет не только читать, но и системно заставлять читать других.

Второго сотрудника такой квалификации ваша фирма себе позволить не может." Если нужен пример, он есть у меня. Фирма 5000+ сотрудников.

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

158
Связей, наверное, должно быть больше.

Например, между удельной мощностью двигателя и дешевизной производства/обслуживания (ибо экстремально высокие значения для текущего уровня производства явно не удешевят изделия).

Или связь между калибром орудия и массой.

Ну а в целом - нормальная такая трассировка. В таком (графическом) виде применима при очень небольшом количестве требований и взаимосвязей, оптимально - на уровне презентации. При детализации превращается в нечитаемую паутину.

159
Первых двух ответов в теме вполне достаточно, на мой взгляд. Поэтому про курьезы ФЛК.

1. Ограничение в ФИО на латиницу и цифры. Латиницу - да, нельзя. Ибо запрещено (было, по крайней мере). А вот цифры могут быть. Начальник московского паспортного стола по этому поводу как-то поделилась из личной практики, что некий не сильно уравновешенный гражданин возжелал стать по паспорту Николаем II-м. На уговоры "не дурить" не повелся, цифру "2" тоже не захотел. В результате унес с собой паспорт, в котором было прописано "Николай 11".

2. С какой радости ограничен максимальный доход? Намеренное вредительство банку, отсечение обеспеченных клиентов?

3. Ограничение триединого поля ФИО - это 50 символов на каждое, или на все? Непонятно. Если на все - то почему так скромно? Кроме Ивановых, российское гражданство имеют и разные депардье с остап-ибрагим-берта-мария-бендер-беями.

Я это к тому, что незнание некоторых нюансов, а также излишняя инициативность могут сыграть злую шутку.

160
Что ни проект - то распил и освоение.

Вам на каждом проекте так вот "глазки строят"? Если да, то я бы подумал о смене места работы. От греха. А то мало ли - вдруг в соучастниках пойдете?

161
А не надо задавать неудобные вопросы. :)

Вот Вам прям так и ответили, что этот проект у нас - для доосвоения всего объема годового бюджета, вот этот - уступка ЛПР заказчика Семен Семенычу с фирмой его сына "Суперсофт", этот - потому, что Екатерина Матвеевна метит в замгены по техническому направлению, этот - потому, что надо заплатить за работы прошлого полугодия, которые были выполнены формально за копейки. А вот этот вообще нам "сверху спустили", и для нас он как серп по тестикулам, поскольку своя аналогичная разработка на этапе завершения (реальный случай).

Как быть? Для начала прощупать почву у своих аккаунтов и продавцов. Не зря же они эти вопросы заворачивают? Два - если клиенты отводят глаза и воротят нос - не надо настаивать, спокойнее спать будет.
А в норме, если проект действительно для дела, то и на контакт идут охотно, и отвечают в меру откровенно.

162
Модернизация ИТ это самое страшное для компании.

Не уверен, что самое. На мой взгляд, руководству часто просто непонятно - зачем?

Менять бизнес структуру, увеличить бюджет на нее - это нормально, но не на ИТ.

А тут как раз все понятно. Инициаторов таких изменений обосновывать потребность учат все, кому не лень. )

Нам (ИТ) что делать в этой ситуации?

Ну, лично я, как последний трус и лентяй, просто меняю место работы, когда достает заниматься производственной мастурбацией. На новом месте с 95% вероятности все точно так же с небольшими вариациями, но глупая надежда и новые ощущения позволяют вернуть желание работать и местами энтузиазм. На время.
Я много личного времени и личных нервов потратил в попытках улучшить ситуацию на местах, но не преуспел особо. С баблом спорить сложно. Теперь вместо ситуации меняю стены.

Мы последнее звено в этой пищевой цепочке. 

Что характерно - даже в компаниях, целиком ориентированных на предоставление ИТ-услуг, все ровно так же. В крупных и сытых, по крайней мере.

И если заказчик "щедрый", то  с нас требуют по настоящему".

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

И бывает так, что проект достаточно сложный и ресурсы ИТ не могут выполнить его в надлежащем виде. Запускаемся как есть и начинается......

Ну, какой бы ни был сложный проект, и на него найдется болт с резьбой. Я чаще сталкиваюсь с другой проблемой: ресурсы и компетенции есть, как делать - более-менее понятно. Но тут приходит яркий представитель более высокого звена пищевой цепочки и заявляет "Три месяца? Не, не пойдет. Я вчера с заказчиком договорился, что черед 2 недели будет готово. Приступайте!". И приступаем. А поскольку за 2 недели можно сделать разве что не очень качественную имитацию результата, то "гордость" за проделанную работу и успешное применение компетенций просто зашкаливает. Ну, зато премию могут дать - как же, за две недели управились! (конкуренты за 3 обещали).

163
Типа" зачем платить больше, если результат всех устраивает?"
Ведь понятно, если процесс улучшать, то надо определенные затраты, усилия и знания.   А лучше не тратиться пока нет никаких противоречий.

По моим наблюдениям, это и есть управленческая максима всех более-менее крупных компаний разработчиков/интеграторов. Что в целом понятно, поскольку что крупные "разработчики", что "интеграторы" в первую очередь "освоители бабла" под выбранной личиной. Через это никаких особых подвижек и достижений на ниве ИТ- или управления ждать не стоит. Особенно таких, на которые надо потратиться.

Есть, наверное, исключения. Не может не быть. Но мне не попадались.

164
Почему назрело:
-ошибок в разработке масса...
-документации по разработке нет...
-контакта с аналитиками нет...

Переименовать и переставить столы? "Эх... А вот когда я молодой в борделе работала,..." (с)

Честно говоря, не вижу, как само по себе изменение оргструктуры избавит вас от этих проблем системного характера. Наверняка вы задумали что-то еще, посущественнее.

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

анализ и разработка - департамент развития,
сопровождение и тестирование - департамент сопровождения.

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

Существенной разницы, как нарезать департаменты, по-моему, нет. Обычно такие вопросы решаются исходя из амбиций и интриг руководителей разного уровня в целях упрочения и улучшения собственных позиций в компании. А будет ли программист, которого посадили кодить проект, числиться в департаменте А или департаменте Б, на мой взгляд безразлично (при условии отсутствия внутренних конфликтов между департаментами).

Гм. Несколько сумбурно получилось.

165
они позволяют сэкономить немалую часть ресурсов заменив бухгалтера, юриста, кадровика и айтишника трудом наемного рабочего.

Одного, да. Причем ему еще и метлу можно выдать.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 »