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

×


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

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


Сообщения - AlexP

Страницы: 1
1
Я бы для начала поставил вопрос так: а кому нужен такой софт?

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

И самый главный вопрос: интересовались ли вы, есть ли, например, в США подобные проекты? Ведь у них гораздо
более развита вся эта индустрия?

2
У меня это выливается в следующие шаги

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

3
.... хотелось бы поднять уровень документирования систем у себя на более высокий уровень.....

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

Т.е.
1. Цель документа
2. Аудитория
3. Шаблон/наполнение

С ув., Саша

4
Обучение / Re: Обучение процессу разработки
« : 16 Сентября 2009, 15:50:59 »
В идеале хотелось бы организовать все так, чтобы группа студентов (21) работала с одним проектом как единым целым. В прошлом году пытался, не получилось.

А зачем? Если говорить о реальном проекте, в котором участвуют порядка 20 человек, то это уже достаточно масштабная система, а то, что есть в презентации, на мой взгляд, лучше подходит для групп по несколько (5-6) человек. Более того, каким образом понять критерии "правильности" или "успешности" выполнения того или иного задания? Почему лучше именно таким образом выделять проблемы, а не другим?

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

С ув., Саша

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

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

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


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

А можно по-подробнее? О каких методиках идет речь?

С ув., Саша

7
Я пытаюсь решать этот вопрос именно с точки зрения Заказчика, а не разработчика... :-)

8
Коллеги, добрый день!

На работе столкнулся с такой задачей.

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

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

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

Может кто-нибудь уже сталкивался с подобный вопросом? Существуют ли какие-либо методики, стандарты?

С ув., Саша

9
ПРоблемы со следующими книгами

1. More About Software Requirements: Thorny Issues and Practical Advice
http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=101

2. Software Requirements, Second Edition   
http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=100

С ув., Александр

10
Все добрый день!

Скачал две книги Вигерса на английском языке из файлового архива. Но, к сожалению, они не открываются. Точнее с левой стороны дерево отображается, а текста нет.

Кто-нибудь сталкивался с такой проблемой?

С ув., Александр

Страницы: 1