16

ПО Аналитика / Re: ПО для формирования доков по ГОСТам

« : 11 Мая 2011, 23:31:07 »

Павел, спасибо. Но там - не нормативные документы, во всяком случае прямых ссылок нет. Те правила, о которых я пишу - мы так сдаем документацию в ЦБ, и они на это смотрят, а номер ГОСТа могу раскопать. Единственное, этот формат примерно 5-летней давности, могли быть изменения. А уродливые списки, когда пункт начинается с маленькой буквы и кончается точкой с запятой, а внутри - точки и предложения с большой буквы сам видел в государственной нормативке неоднократно. Ну и даже если смотреть те правила, то с моей точки зрания они не слишком удобны - и эстетически и практически. Главное - я не понимаю, зачем это обязательно регламентировать стандартом. Хотя и согласен с автором, что разнобой - это тоже плохо

17

Для всех / Re: Пример описания предметной области с использованием UML

« : 06 Мая 2011, 12:17:55 »

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

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

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

18

Обсуждение статей / Re: О статьях

« : 05 Мая 2011, 00:17:37 »

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

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

Да, от статьи все это ушло далеко, тут я извиняюсь.

19

Обсуждение статей / Re: О статьях

« : 04 Мая 2011, 23:57:37 »

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

Соответственно, приведенные пассажи - они просто следуют из этих намерений. Ну, не могли авторы написать, что unintelligible words - 100%, вот и написали - 90 and more. А эффект - два порядка - более впечатляющ, чем вдвое, это тоже очевидно. Ну а пример - понятно, что он плюшевый. Особенно  "самая интуитивная система" - это же вообще непонятно как рассматривать серьезно.

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

20

Обсуждение статей / Re: О статьях

« : 02 Мая 2011, 09:18:39 »

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

В принципе - типичный прием. Вообще я не так давно прочитал замечательную книгу по всяким рассуждениям - Поварнин, Искусство спора. Это начало 20 века, когда к спорам и вообще слову относились серьезно. Там классификация дискуссий по целям и методам и приемы в них. Скачать можно http://www.koob.ru/povarnin_sergei/iskusstvo_spora но такие книги я бы читал на бумаге (правда не факт, что она есть в широкой продаже)

21

Тестирование / Re: Тестовые примеры

« : 20 Марта 2011, 12:01:03 »

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

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

22

Идеи и мозговой штурм / Re: Можно ли продать ТЗ и как это сделать?

« : 13 Марта 2011, 23:01:18 »

ТЗ как детально проработанную постановку на некоторую будущую систему продавать, по-моему, не реально. Потому что детальное ТЗ - штука сложная и трудоемкая, понять и оценить его непросто. А инвестор - он оценить должен.

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

23

UML SysML и пр. / Re: Почему Вы используете или не используете UML?

« : 13 Марта 2011, 22:54:05 »

41-50. Активно использую UML при создании постановок. Вообще UML используется в нашей компании с где-то с 2002 года, и я был одним из инициаторов. 

Активно используются диаграммы классов и диаграммы состояний (для документооборота). Когда уместно - диаграммы деятельности, диаграммы последовательностей и другие. Для рисования используется visio с шаблонами от http://www.softwarestencils.com/. Мы воспринимаем UML как удобный и разнообразный набор диаграмм со стандартной нотацией. А сами диаграммы - рассматриваем как необходимую часть постановок. В общем, по Фаулеру (UML distilled).

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

24

Обучение / Re: Системный аналитик курсы

« : 14 Февраля 2011, 10:10:14 »

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

25

Управление Проектом / Re: Особенности работы с госзаказчиками

« : 14 Февраля 2011, 09:55:55 »

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

Далее, с этими людьми согласуется каким образом другим структурам заказчика проект будет представляться и сдаваться, проходя необходимые процедуры. Включая документацию. Соответственно, в деньги проекта должны быть заложены затраты на деятельность, связанную со сдачей и прочими орг.мероприятиями, которая обусловлена особенностями заказчика. В зависимости от конкретных условий у заказчика ее объем может доходить до 70-100% к основной работе по проекту, поэтому ее надо реально закладывать.

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

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

26

Для всех / Re: Юнит тесты и работа аналитика.

« : 31 Января 2011, 22:54:34 »

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

27

Для всех / Re: Юнит тесты и работа аналитика.

« : 31 Января 2011, 22:52:24 »

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


Это - идеальная картина. Реально может быть всякая комбинация, в зависимости от конкретной области. Классическая (водопадная) модель больше рассматривает продуктовый вариант. SCRUM дает некоторую комбинацию: с одной стороны, члены команд проверяют работу друг друга, выделенной роли тестировщика нет но деятельность - есть, а вот Product Owner является аналитиком, формулируя требования, и он же принимает результат.

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

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

28

Управление Проектом / Re: Нормативы на доработку ПО

« : 26 Января 2011, 21:16:41 »

В посте - завуалированное предположение: IT систематически завышают оценки и бездельничают. Факт состоит в том, что с этим невозможно бороться регламентами. Надо разбираться.

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

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

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

29

Книги, статьи и ресурсы / Re: Влад В. Головач Дизайн пользовательского интерфейса 2. Искусство мыть слона

« : 30 Декабря 2010, 00:47:51 »

Не удержусь от маленькой рекламы в тему. У нас в 2009 Андрей Бибичев проводил семинар на тему usability интерфейсов, и он выложен здесь. Там был обзор разных книг плюс опыт...

30

Проектирование / Re: Проект по уму на VP

« : 23 Декабря 2010, 11:42:30 »

Уровень постановки задачи программисту зависит, прежде всего, от уровня программистов. А второе - от уровня сложности разрабатываемых програм и интерфейсов. У нас был опыт работы в двух разных парадигмах. (1) слабо квалифицированные программисты (типа студенты), которые делали типовые интерфейсы - там было специфицировано - что есть типовой интерфейс (таблица с фильтром для просмотра, форма-диалог для редактирования), а дальше для интерфейса писали списки конкретных полей плюс отличия от типового (дополнительные кнопки, например). (2) - постановка для квалифицированных программистов в случае сложных, нагруженных интерфейсов - тут расписываешь прецеденты (usecase), которые хочешь улоджить, либо пишешь "сделать (пока) простой интерфейс для документа XXX" (документ - это класс + схема переходов по состояниям), если ничего сложного нет или неясно. При этом понятие типового интерфейса в проекте - тоже есть (как стиль кодирования). Вообще говоря, аналогично и с постановками на НЕ интерфейсную часть, они сильно различаются для разных уровней исполнителей, но тут сложнее. Да, есть еще третий кейс - программисты квалифицированные и с самомнением, но работать хотят по спецификациям "для тупых" - таких стоит гнать. А какие программисты у Вас?