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

×


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

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


Сообщения - Григорий Печенкин

46
Офис расположен в районе Сити, рядом – парк, фитнес.

В Лондоне?

47
Взаимодействие и обзвон поставщиков, в части предоставления коммерческих предложений
...
логические функции: ЕСЛИ, И, ИЛИ, ЕСЛИ ОШИБКА

Не вакансия, а мечта. :)

48
Добрый день!

При описании раздела пользовательских интерфейсов в спецификации требований возникла спорная ситуация:
необходимо ли описывать мелкую анимацию (например: постепенное исчезновение удаляемой вкладки за определенное время).

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

Хотелось бы услышать Ваше мнение по данному вопросу.

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

Чем мотивируют свои предложения те, кто хочет видеть эти требования в другом документе?

50
Получается, что меня как раз интересуют возможные виды "классификации инцидентов" (в вашей формулировке), т.е. по каким критериям можно как раз разграничить эти 3-5 уровней их критичности.
Например, что пришло мне на ум:
1) Как раз разграничить по трудоемкости работ, разумеется по оценке исполнителя, а не заказчика (в вашей формулировке = стоимости доработок).
2) Приоритетности доработок для заказчика, например, высокоприоритетные и высокотрудоемкие не более Х, высокоприоритетные и низкотрудоемкие не более У, низкоприоритетные и высокотрудоемкие не более К и т.д.
3) Трудоемкость доработки определять исходя из количества дорабатываемых подсистем.

Может есть еще какие-то критерии?


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

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

Есть ещё такое волшебное слово - SLA :)
Вот здесь (последний пост) есть типичная классификация проблем по сложности, а также примеры времени реакции на проблемы:
http://www.itsmonline.ru/community/viewtopic.php?t=37

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

51
Работа / Re: Начало карьеры
« : 31 Августа 2016, 12:36:08 »
Григорий, а что по вашему мнению стоит использовать в данном случае?

Если нужно описать требования от целей создания продукта до уровня ролей пользователей и функций, то я бы начал с Концепции. Вот здесь есть неплохой набор шаблонов, можно взять шаблон концепции из него. http://michaelsmirnov.blogspot.ru/2011/02/blog-post.html

На более низком уровне можно попрактиковаться в разработке SRS по стандарту IEEE 830 или по рекомендациям Вигерса (это практически одно и то же): https://ru.wikipedia.org/wiki/Спецификация_программного_обеспечения

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

ГОСТы дают шаблоны, но ничего не говорят о том, как нужно работать с информацией для их заполнения. Многие термины устарели, и люди пишут туда всякий бред из-за того, что не понимают значения этих терминов. Вот здесь примеры наиболее распространённых ловушек: https://www.webursitet.ru/article/terminologicheskie-lovushki-gost-34.html

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


52
Работа / Re: Начало карьеры
« : 31 Августа 2016, 00:46:03 »
Не надо разрабатывать по ГОСТам ТЗ на блог. Блог – это не программное изделие (тьфу, слово-то какое). Технико-экономическое обоснование, требования к макировке и упаковке – вам это всё надо?

И тем более блог не автоматизированная система, прости господи.

ГОСТ умер, не надо тащить этот труп в интернет-проекты.


53
в лидере рынка СУТ 3SL Cradle

В этом месте должна стоять звёздочка со ссылкой на результаты исследования рынка.

54
Главное – не использовать такие картинки в реальных проектах.

55
Это головоломка? Чем отличаются диаграммы 1 и 2?

56
Добрый день!
Пишу спецификацию, где для каждого ВИ расписывается его карточка.

Ситуация такая: у нас есть ВИ, но шаги в этом ВИ существенно отличаются в зависимости от предусловий.

Если предусловия разные, то и ВИ разные.
Как это оформлять - зависит от того, что вы потом делаете с этими карточками.

57
А почему? Чем чревато?

Тем, что вместо сайта получится АС. :)

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

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

Потребителя услуги регламентировать нельзя. Если продукт предназначен для решения сравнительно сложных специальных задач, можно дать ему рекомендации в виде руководства пользователя. Но не в том составе и не в тех форматах, которые предлагаются стандартами для АС. Иначе он проголосует ногами и деньгами за продукты конкурентов.

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

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

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

В вебе такое отношение к пользователям не пройдёт.

58
Просто приклею это сюда и улечу.

Интересно, а почему на картинке из книги Коберна Writing Effective Use Cases стоит копирайт какого-то Capgemini?

Но вообще, именно эта концепция пяти уровней в книге самая запутанная, и она не даёт ответа на вопрос, что считать функцией.

59
Вакансии / Re: Разработчик Android (ДБО)
« : 21 Июля 2016, 16:43:37 »
а может у аналитика есть друг разработчик и он его порекомендует?;)

Не делайте так, пожалуйста. Из-за этого погиб яндексовский moikrug - рекрутеры его убили. Когда количество опубликованных вакансий "вдруг кто порекомендует" стало лавинообразно нарастать, все пользователи, кроме рекрутеров, его покинули.

60
Вакансии / Re: sales менеджер (АйТи)
« : 21 Июля 2016, 16:07:42 »
В ГК "АйТи"  нужен СРОЧНО Sales менеджер! По з/п от 100 т.р.

Ну ещё про клининг-менеджера здесь напишите.