1

Варианты Использования (Use Case) / Re: Насколько ПО должно быть близко к реальности?

« : 15 Октября 2010, 11:59:48 »

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

Разумеется - это нормальное явление. К тому же мы обсуждаем здесь только один блок и одну проблему,  может быть в целом система вполне замечательная:)

на самом деле совсем не так

Ооопс...Кажется я по невнимательности не вполне верно понял ситуацию из примера, отсуда поспешные выводы. Хотя было ясно написано "готовая".
Т.е, заказчик решил приобрести некую не для него разработанную систему, и в процессе внедрения вылезла описанная проблема?
Или не совсем так?

Архитектура и три Д как обычно

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

Реально была. И была точно и четко поставлена изначально.
Все было выявлено и определено. Было явно сказано, что информация о надбавках должна каким-то образом прикрепляться к сотруднику и можно эту информацию просматривать.Скорее причина. Реализация кадровых задач была ранее сделана, а по надбавкам уже доделка.

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

Возможно, правда разработчик не использует ВИ как средство специфицирование требований.

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

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

Возможно

2

Варианты Использования (Use Case) / Re: Насколько ПО должно быть близко к реальности?

« : 15 Октября 2010, 11:29:57 »

.... Многое зависит от тщательного и продуманного анализа. Но ... возможно ли учесть все нюансы?

Однозначно можно ответить - все ньюансы в аналитической модели учесть невозможно, потому что:
а) Любая модель по определению является упрощением, учитывая только существенные свойства моделируемого объекта, абстрагируясь от несущественных.
б) Бизнес-процессы имеют свойства изменяться во времени, любая модель устаревает
в) Модель отражает только типовые процессы, а в реальной жизни всегда возникают случайные отклонения от типичной схемы, которые заранее учесть невозможно
г) Любая модель субъективна, взгляды и понимание у всех разное + всем людям, включая аналитиков, свойственно просто ошибаться
и т. д.

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

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

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

3

Варианты Использования (Use Case) / Можно ли достичь нужной гибкости ПО?

« : 14 Октября 2010, 16:44:55 »

Насколько я понял из описания примера, в процессе эксплуатации готовой системы возникла проблема, и требуется доработка с целью ее устранения в рамках сопровождения. Это одна часть истории (второй, третий и четвертый извечные вопросы - Что делать?, Кто заплатит за банкет? и Где взять деньги? .
Но при этом хочется выяснить, отчего возникла проблема в первоначальной версии  (первый и самый главный вопрос Кто виноват?
IMHO это именно недоанализ: потребность Необходимо предоставить сотруднику штатного расписания права на ввод и редактирование надбавок не была выявлена. Это была задача Аналитика при выволнении работ по Анализу  требований - ее обнаружить, зафиксировать в том или ином виде в ТЗ (Спецификации требований) и согласовать с Заказчиком (здесь непринципиально, если если Заказчик сам проводил Анализ требований составлял ТЗ - тогда он и есть Аналитик). А недопроектирование -уже следствие.
Ну а ВИ здесь только один из возможный инструментов - упомянуть стоит хотя бы только потому, что тема про ВИ, а то будет совсем уж голимый офтопик . Если бы работа Настройка надбавок была бы выделена в виде ВИ с ДЛ Сотрудник штатного расписания, было бы очевидно, что для последнего нужны права к доступу при раздаче прав по ролям - этого было бы достаточно.
Модель ВИ рисует Аналитик  на стадии Анализа требования.
Проектироващик конечно тоже может конечнопорисовать (даже если Аналитик такую модель не делал), но это уже будет модель сценариев реализации (ВИ со стереотипом Use-Case Realization) и расписать для них ход процесса, нарисовыать диаграммы последовательностей и взаимодействия и т.д. Говорить о длительности наверное лучше применительно к последнему виду ВИ.

4

Управление Проектом / Re: Дружеские отношения или жесткая корпоративная этика

« : 14 Октября 2010, 12:12:14 »

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

Иногда это верный способ потерять и друзей и бизнес. А если это родственники - то еще и испортить отношения в семье.
Это так, бухтение на правах офтопика:)

5

Варианты Использования (Use Case) / Можно ли достичь нужной гибкости ПО?

« : 14 Октября 2010, 12:04:12 »

Ошибка в требованиях, если уж быть точным. Достаточно было предусмотреть ВИ что-то типа "Назначение и снятие надбавки" с ДЛ  "Сотрудник штатного расписания", и проектировщик бы этот вопрос продумал.

6

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 13 Октября 2010, 11:13:30 »

А прибивание спонтанного творчества - оно плохо сказывается на мотивации и моральном состоянии авторов этого творчества. Они же старались. Так что тут в обе стороны проблемы быть могут...

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

7

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 12 Октября 2010, 22:25:13 »

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

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

8

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 15:25:56 »

А вот тут я уже, извините, упустил смысл продолжения спора. Если правильно понял, вопрос был о формализованных рекомендациях, которые описаны в стандартах и формальных описаниях процессов типа RUP. Да, они там есть, но в конечном счете сводятся все к тому же - собрать заинтересованных лиц в одной комнате и попытаться привести к согласию:
To conduct a requirements workshop, means to gather all stakeholders together for an intensive, focused period.
Есть еще советы по подготовке и ведению совещения, ничего особо сверъестественного.
А вот рекомендаций, какими словами убеждать участников, и что делать в случае провала там нет.

9

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 09:25:44 »

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

Формально процессы заказа/поставки/разработки описаны в ГОСТ/ISO 12207 и внутри них - процессы совместного анализа и совместного решения проблем.
В RUP в описании дисциплины Requirements есть кое-какой формализм  (см. например активность Analyze the Problem и в ней Requirements Workshop - то самое собрание).
Еще есть советско-российская бюрократическая традиция совещаний с составлением протоколов разногласий (что формально описано - неи знаю, но точно можно найти образцы документов).
По идее должны быть аналоги в описаниях других процессов.

10

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 08:58:02 »

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

Хороший способ, надо запомнить

11

Проектирование / Re: Постановка задачи программисту

« : 11 Октября 2010, 19:17:28 »

2 maksiq

Вообще-то моя реплика про псевдокод была ироничным ответом на конкретную фразу:
Алгоритм действий для разработчика это должно быть:
Цитировать:
Открой редактор кода.....и т.д.
и содержала в себе большую долю шутки (смайлики там были )
Но и серьезный остаток тоже там есть.
Любые тяжелые методы анализа и проектирования стоит применять выборочно, только тогда когда в них есть обоснованная необходимость. Это относится кстати говоря и к графическим нотациям - тома диаграмм бизнес-процессов производят конечно впечатление на неискушенных клиентов и начальников, но отношение практической пользы для разработки к трудозатратам у них весьма сомнительное (IMHO конечно, может кому и помогает).
Расписывать сколько-нибудь подробно все подряд в системе - это совершенно бездарное занятие (среди всего прочего - программисты быстрее кодируют, чем проектировщик пишет ). Но критические и сложные для понимания процедуры документировать может быть в некоторых случаях целесообразно. IMHO стоит подробно документировать серверные процедуры, реализующие бизнес-логику и ограничения  (разделение логики по слоям - другой вопрос). Не увлекаясь при этом подробностями - только логику упрощенно, без деталей реализации - что откуда берется и куда кладется.  Перегнать потом в PL/SQL или TSQL, оптимизировать и отладить - задача простая, но не тупо тривиальная. Нотация будет конечно не вполне классический псевдокод (как в учебниках инфоматики) - скорее русский естественный структурированный язык:).

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

12

Проектирование / Re: Постановка задачи программисту

« : 08 Октября 2010, 21:47:26 »

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

Говорят ПОЧТИ правильно - не обязаны прогеры разбираться в хитросплетениях финансовых алгоритмов, у них от своих забот голова пухнет. Вот только адресовать свой вопрос они должны не аналитикам, а проектировщикам. У аналитиков своих забот хватает, про поля таблиц они могут ничего не знать.
Для этого нужен специальный человек, который на первый взгляд, вообще не понятно в чем разбирается: он хуже знает бизнес, чем аналитик, и хуже программирование, чем программист. Зато может выступать переводчиком с аналитического на программерский:))

13

Проектирование / Re: Постановка задачи программисту

« : 08 Октября 2010, 21:30:01 »

Алгоритм действий для разработчика это должно быть:

Алгоритм действий для разработчика это должно быть:
Цитировать:
Открой редактор кода
Напиши #include <stdio.h>
Напиши void main() {
…

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

14

Проектирование / Re: Постановка задачи программисту

« : 08 Октября 2010, 21:19:55 »

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

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

15

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 16:02:20 »

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

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

После этого (когда вопросы прибыльности решены и принято решение ввязаться-таки в этот *?:%;%:?*?: проект) формируется рабочая группа и начинается (хотя на практике и люди могут быть определены ранее, и работы могли уже выполняться и т.п.) проектная работа-борьба за "уложиться в бюджет"...

---------------- обличительная часть выступления закончена :о)))

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

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

P.S. кстати, а что же будет делать аналитик (обеспечивший молчаливое "согласие") на стадии сдачи, когда риск реализуется и проблема всплывет на более высоком уровне критичности? заявление об уходе писать?

Конечно ничего хорошего не будет, ктож спорит. Нужно на более ранних этапах добиваться явного согласования ТЗ. Но, если уж не удалось никак, в качестве последнего рубежа обороны может и сработать ("Ну Вы же согласились...").