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

×


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

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


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

Страницы: « 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 »
241
Методологии / Re: Обзор методологий
« : 08 Апреля 2015, 16:00:34 »
Пример: "ТЗ по ГОСТу" на сайт.

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

Даже если заставить их изучить все документы ГОСТа, они всё равно их поймут неправильно, потому что жизненный цикл их продукта не имеет с гостовским ничего общего.

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

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

Так понятнее. Просто в предыдущем сообщении я прочел несколько иное. Примерно "применяют ГОСТ не приходя в сознание - и отчасти так и надо". :)

242
Методологии / Re: Обзор методологий
« : 08 Апреля 2015, 13:03:31 »
Предлагаю начать с области знания Enterprise Analysis артефакт: Business need https://drive.google.com/file/d/0B6-Yeg85Oh9jMWRSMlJhT2pTZms/view?usp=sharing стр. 81

Насколько я понял из вражьей мовы, содержание документа приведено в п.5.1.4.

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

Наиболее полное соответствие усматриваю с ГОСТ 7.32, в просторечии "Отчет об обследовании" (см. Приложение 1 к РД 50-34.698-90). Оформляется где-то до разработки ТЗ. На практике я с необходимостью разработки такого документа столкнулся всего один раз, и тот был не про разработку концепции, а являлся по сути отчетом за освоенные на этом этапе деньги. Так что не могу считать себя сколь-нибудь компетентным специалистом по этому виду документации.

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

243
Методологии / Re: Обзор методологий
« : 08 Апреля 2015, 12:46:40 »
Люди массово используют шаблоны ГОСТа, не читая сам ГОСТ. И я не могу сказать, что они совсем неправы.

Можно развернуть мысль из последнего предложения?

244
Методологии / Re: Обзор методологий
« : 08 Апреля 2015, 10:10:09 »
Леонид, конечно делись. А там посмотрим поможет или нет  ;)

Предлагай артефакт. С описанием его содержания или ссылкой на оное. :)

245
Методологии / Re: Обзор методологий
« : 07 Апреля 2015, 15:58:53 »
Возникла необходимость смаппить артефакты RUP и ГОСТ на артефакты нашумевшего BABOK.

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

246
Методологии / Re: Обзор методологий
« : 07 Апреля 2015, 15:55:04 »
и даже если в результате выяснится, что действительно лучше не мапить.

Детей жалко. И их заказчиков. Выяснять-то они будут, опытным путем. :)

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

247
Для всех / Re:
« : 24 Марта 2015, 17:53:12 »
Спасибо за наводку. Буду посмотреть.

Вас ждет целый новый мир, полный замечательных открытий. Я даже немного завидую. :)

работаю там, где ГОСТы не применяются.
зато все уверены, что применяется одно из базовых принципов Agile: "Working software over comprehensive documentation" - Работающая программа важнее, чем подробное документирование.

Да, таких мест полно. Во избежание лишних трений, можно не дразнить гусей словом "ГОСТ". Можно просто им руководствоваться.
Принцип, кстати, замечательный. Теплое однозначно важнее, чем мягкое.

так то оно так, но бизнес-приложения - это особый случай

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

, так как их логика описывает процессы существующую  внешнего мира, я не какую то внутреннюю, самодостаточные логику.

Страшное по своей разрушительной силе утверждение.


А эти процессы внешнего мира имеют свойства меняться время от времени...

Да. Для отражения изменений документацию актуализируют.

248
Для всех / Re:
« : 24 Марта 2015, 17:21:32 »
Гм... Ну, исчерпывающий подход к документированию "проектов" закончили продумывать и оформили еще четверть века назад. Это ГОСТ 34 серии. Я до сих пор не сталкивался с проектами (а сталкивался с достаточно большими и серьезными), с которыми он бы не "справился".

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

249
Коллеги, заказчик просит разработать ему документацию по тех.проекту (РД 50-34...), но мы не разрабатываем Систему (как это описано в док. для РД 50) мы дорабатываем (модифицируем) свою систему под требования заказчика.
Вопрос в том, как правильнее в этом случае описывать в документации систему по  РД 50 - разработку или все таки доработку Системы? (вопрос в формулировках в документах).

Это зависит.

Как составлен контракт? За что платит заказчик?

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

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

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

П.С. РД 50 глубоко безразлично, о чем вещать - о разработке или доработке. Это всего лишь вопрос контента, который раскладывается по документам. А контент, разумеется, разный - и не столько в формулировках.

250
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 26 Февраля 2015, 12:41:59 »
Я прямо вижу, как в этом топике на глазах вырастает готовый раздел "FAQ по ГОСТ 34" для сайта.

Будут появляться "Q", может и наберется достаточно материала. :)

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

251
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 26 Февраля 2015, 11:16:02 »
Немного про жизненный цикл требования в 34 ГОСТ на примере из первого поста темы.

1. Вот есть у нас в ТЗ такое требование:
"- Внесение кредитной оценки УП"
И больше никакой конкретики. С точки зрения аналитика - тихий ужас, а не требование. Однако, "не все так однозначно". Это всего лишь ТЗ.

2. После согласования ТЗ систему начинают проектировать (Ну, в теории. Чаше сразу бросаются кодить, но мы ж про то, как правильно). В процессе проектирования пишутся спецификации или, если уж совсем следовать ГОСТ, разделы документации технического проекта. В которую должны войти:
- общее описание процесса "внесение кредитной оценки УП" (с разделением на человеческую, машинную, внутрисистемную, внешнюю и т.п. составляющие);
- описание автоматизированных в рамках этого процесса функций (например, "регистрация новой карточки УП", "поиск карточки УП", "внесение кредитной оценки в карточку УП", "форматно-логический контроль кредитной оценки" и т.п.)
- описания интерфейсов (как GUI, так и API);
- описание ролей, которые занимаются этой работой в системе;
- описание информационного обеспечения этого процесса (входные и выходные сообщения, логическая модель данных, физическая модель данных, применяемые справочники и классификаторы);
- и т.д. (см. РД 50-34.698-90).

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

3. Далее (помимо кодинга) разрабатывается рабочая (в т.ч. эксплуатационная) документация, в которой будет рассказано, на каком сервере будет развернут этот функционал, как им пользоваться и т.п. И самое главное - будет разработан документ "Программа и методика испытаний".

В этом документе исполнитель предложит один или несколько методов (кейсов, если угодно) испытания исполнения требования ТЗ "- Внесение кредитной оценки УП". Обращаю внимание - проверяется требование ТЗ, а не решения технического проекта. Поэтому испытаний может быть (и должно, пожалуй) сильно меньше, чем требуется для "покрытия" всего содержимого техпроекта.

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

4. На испытаниях всякое бывает. Раз - и не сработало. В этом случае систему дорабатывают в сроки, определенные комиссией, и представляют на повторные испытания (или уже на финальные, см. ГОСТ 34.603-92).

252
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 26 Февраля 2015, 10:39:56 »
Уже вне статьи, про ГОСТ 34 вообще.
Нужно понимать, что 34 серия ГОСТ - это целостная система. Вырвав одну из ее частей из контекста (например, ТЗ по 34.602), не всегда очевидно, почему эта часть устроена так, а не иначе (потому, что устроена она так для интеграции с остальными частями).
Разумеется, 34.602 можно применять без оглядки на остальной 34-й (весь технорабочий проект), но при этом желательно четко представлять, от чего в конкретных условиях можно отказаться (поскольку "продолжения" не будет), а что желательно оставить на месте.
И да, 34.602 неплохо подходит даже для проектов разработки ПО. Нужно просто "отсечь все лишнее" (каким образом - писать ли "требования не предъявляются" или просто не упоминать ненужные разделы, зависит от обстоятельств).

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

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

253
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 26 Февраля 2015, 10:09:21 »
"Забыта услуга «Инсталляция ПО»"
"Забыта услуга «Миграция данных»"


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


"Ну и, конечно же, достаточно тяжело продавать современную банковскую систему, если в реестре товаров и услуг нет услуги «Обучение персонала»."

Совершенно верно. Подготовка персонала - одна из важных составляющих создания системы, без которой просто "не взлетит". По поводу чего ГОСТ нам рекомендует включать в ТЗ "требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков;".

"И не нужно давать написание ТЗ системному аналитику. Ответственность за написание ТЗ лежит на главном конструкторе."

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

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

* * *

По статье - все. Готов отвечать на вопросы.

254
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 26 Февраля 2015, 09:43:07 »
"Так, например, раздел «5) состав и содержание работ по созданию системы» это явно документ планирования, ответственность за который несет руководитель проекта."

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

Но обычно ТЗ рассматривается в первую очередь как документ требований к разрабатываемому ПО.

И в этом кроется большая ошибка. Выше писал, почему.

"Но как только мы примем, что это требования не столько к ПО, сколько  ко всей совокупности изменения процесса, все становится на свои места.
Примечание. Это, знание похоже так осталось в 90-х."


Ну, знание до сих пор живо. Пока еще. :)
И совершенно верно - 34 серия ГОСТ не про ПО, она про создание систем. ГОСТ покрывает весь процесс, от зарождения сомнений "а не слишком ли много мы делаем руками?" до выведения системы на реальный бизнес-выхлоп и сопровождения ее жизнедеятельности. (ГОСТ 34.601-90)
Причем ПО во всем объеме необходимых телодвижений может занимать очень малую часть.

"Изменения со стороны исполнителя ТЗ, делаются за счет поставляемых этим исполнителем товаров и услуг."

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

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

"Если поставляются сервера, то возникают требования по электробезопасности и прочие."

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

"Если поставляются тренинги, то появляются требования к навыкам персонала"

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

"Чего в 34.602 не хватает для более простого его понимания, так это раздела «Реестр поставки». Реестром поставки я пользуюсь несколько последних лет, и это экономит мне кучу нервов."

ТЗ  по 34.602 в первую очередь посвящено работам. Даже раздел требований к техническому обеспечению - он про то, на какой технике должна работать система (а не сколько и когда ее должно появиться). А вот для поставок чего-то готового/тиражируемого в ГОСТ 34.201 предусмотрен документ "Ведомость покупных изделий". Вот туда прекрасно ложатся железки, лицензии и т.п.  (документ технического проекта). В ТЗ же, в упомянутом выше 5-м разделе пишется, что на таком-то этапе будут выполнены поставки чего надо. Кстати, именно 5-й раздел ТЗ предлагаю рассматривать в качестве "реестра поставки" (если я правильно понимаю его смысл: документ, в котором перечислено все, что заказчик получит за свои деньги).

255
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 26 Февраля 2015, 09:05:56 »
Начну, пожалуй, со следующего утверждения.

ТЗ в 34 серии ГОСТ (а именно, 34.602) - это документ не для программистов.

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

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

Ну а теперь непосредственно к статье.

Страницы: « 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 »