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

×


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

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


Сообщения - Водолей

Страницы: 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 35 36 37 38 39 40 41 42 43 44 45 46 47 »
1
признаться давненько уже не брал в руки шашки.
но если поможет, могу прислать книжку по SP, но на языке вероятного противника ))) книжка, кстати, тоже с тех времен...
если что пиши в личку

2
Цитата: skillu
Но ВИ нужно тоже согласовывать с заказчиком, ведь это отличный способ показать как система будет работать, а не просто требование, что должно быть. И как я понимаю, все ВИ можно складировать в отдельные текстовые документы, группируя в папки (по актору, подсистеме или по др. атрибутам) ?

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

а оформлять... да как хотите, так и оформляйте... Важно, чтобы это было удобно и понятно и заказчику, и исполнителю. Цель ведь не наплодить документов, а внятно описать все существенные аспекты разработки. Содержание первично - форма вторична. Хорошая структура = хороший инструмент.

3
Цитата: skillu
получается, что ВИ я создаю для выявления и конкретизации функциональных требований, так? И дальше (если требования составлены без ошибок), созданные ВИ остаются не нужными, за исключением использования их для тест кейсов или просмотра их программистами ?

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

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

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

5
IDEF ARIS BPMN и пр. / Re: Механизмы
« : 29 Ноября 2012, 00:50:58 »
BPWIN (или как он там называется) ведет справочники автоматически.

6
Так вы сначала определите ЧТО заказчик хочет увидеть в вашей "спецификации технических требований"? IMHO всего лишь все зависит от степени детальности описания. Или вам важнее соблюсти некую формальную букву хоть какого-нибудь официального стандарта, чем создать документ для работы?
То что вы написали выше: "входные и выходные данные, прототипы интерфейса" делают документ "техническим", а его заказчику трудно читать. Замкнутый круг получается.

Вы в России? Почему не подходит ГОСТ 34.602-89? Там вполне четкая структура требований. Ну выкиньте "слишком технические" разделы и обзовите это ТТ.

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

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

9
Цитата: Galogen
спасибо за идею, но что за софтина?

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

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

10
делали мы одну систему ...э... аналитической обработки статистической информации (возможно, я тебе рассказывал об этом).
поясню пару ее технических особенностей.
в Excel размечаем (по определенным правилам, ессно) некую форму, неважно: для ввода или отображения (в смысле отчетную), сохраняем как xml
затем с помощью софтины сохраняем в системе, что позволяет:
 а) использовать web-форму (сформированную по этому xml-файлу) для онлайнового ввода данных и сохранения их в БД
 б) выгружать из системы форму для ввода в формате Excel для оффлайнового ввода данных и их последующего аплоада в БД
структура БД ессно также формируется по xml-описанию

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

дарю идею... ))))
весь софт написан компанией-аутсорсером где-то за три месяца. дело было года 4 назад.

11
Цитата: Galogen
я так понимаю ты меня одобряешь:)

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

Цитата: Galogen
не следует ли ее переименовать в системы управления процессами или автоматизация процессов управления?

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

12
Цитата: 474
В первом сообщении начиная со слов "Хочется в итоге иметь что-то такое, что позволит указать пользователю свои параметры" речь как раз о "модели конкретного спортсмена" речь и идет.

1. Не надо оправдываться. Оправдываться - лоховство (с) )))))
2. Я не умею читать между строк
3. И все-таки (судя по вашему исходному тексту) речь таки идет скорее об антропометрических данных.
4. Еще раз посоветую обратиться к соответствующей литературе, дабы все-таки разобраться в предметной области

13
работоспособный

14
Цитата: Galogen
Я бы хотел спросить у сообщества помощи в определения списка подобных систем как платных, так и бесплатных.

существуют как минимум два класса систем: BPMS и Simulation
из последнего, что я видел, могу сослаться на систему Metasonic (только он дюже дорогой). основное ее свойство: моделирование (формальное описание) процесса + возможность его исполнения. в чем заключается исполнение процесса, я пока не в курсе. может со временем и до этого дело дойдет.

а так и в АРИСе есть симулятор и в BPWine (не знаю как он сейчас называется).

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

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

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

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

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

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

Страницы: 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 35 36 37 38 39 40 41 42 43 44 45 46 47 »