3751

Примеры / Re: Создание моделей вариантов использования

« : 31 Октября 2008, 21:57:30 »

Можете мне хотя бы намекнуть, каким образом можно описать цель "Учесть товары, переданные контрагенту"

Кто лучше вас может ответить на этот вопрос? Но я попробую.

Цель - это некое состояние, которое мы хотим достигнуть. Что мы хотим достигнуть в "Учесть товары, переданные контрагенту". Действительно ли это наша цель? Или это задача, которую мы должны выполнить, чтобы достигнуть чего-то, что и будет конкретной целью?

Однако можем ли мы сказать, что пользователь желает, хочет, обязан "Учесть товары, переданные контрагенту". Кажется вполне разумным. Но что такое учесть? Записать в журнале список товаров и имя контрагента? Внести в базу данных накладную, которая фиксирует факт передачи товаров контрагенту? Чувствуете разницу между учесть и записать, фиксировать факт. Конечно, можно оставить и учесть, если это понятно и понимаемо без всяких возражений.

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

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

3752

Консалтинг и Внедрение / Re: Необходимость внедрения отраслевого решения. С чего начать?

« : 31 Октября 2008, 18:39:09 »

To bas:
не совсем понимаю смысл выражения "Концепция системы". Не могли бы пояснить? Имеется в виду общие требования?

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

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

3753

Примеры / Re: Создание моделей вариантов использования

« : 31 Октября 2008, 18:35:43 »

Ногами сильно не пинайте. Я только встал на путь анализа и проектирования. До этого заказы мы выполняли "по наитию".
То что ЮзКейс - это цель - я понял из книги Коберна (хотя книга далась тяжело). Но почему не возможна декомпозиция цели - я не понимаю. Допустим Цель - "Учет товаров переданных контрагенту". Что бы достичь данной цели пользователь должен 1."Передавать товары контрагенту" и т.д.
Чем не декомпозиция?

Цель декомпозируема - это факт. Но ВИ не функция, ВИ отражает цель пользователя, а не является ее сам по себе. ВИ это способ использования системы для достижения ЦЕЛИ. Естественно возможны варианты. Эти варианты и описывает ВИ. Такие варианты называются для ВИ сценариями. Сценарий может быть успешным - цель достигнута, и не успешным - цель не достигнута или достигнута лишь частично. ВИ - это соглашение о том, как пользователь использует систему, чтобы достичь своих целей - в данном случае выполнить свои функциональные обязанности. Можно ли назвать целью Напечать отчет? А зачем? не есть ли отчет результат достижения цели?
ВИ - можно сказать транзакция - она или выполняется или не выполняется. В ходе транзакции выполняются разные ФУНКЦИИ, обладающие АЛГОРИТМАМИ. Вот функции можно декомпозировать, а как декомпозировать ВИ - на шаги? А разве шаг есть часть цели (подцель)? Конечно нет!

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

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

Если вы используете понятие бизнес ВИ, то по сути описываете вариант использования бизнес-системы, т.е. некоторый бизнес-процесс. Описываете как складывается взаимодействие.

Бизнес ВИ не декомпозируется - а реализуется через часть пользовательских ВИ, задает для них контекст

Пока писал ответ - пришла в голову мысль: "А можно ли назвать "Учет товаров переденных контрагенту" целью?

Цель имеет два состояния - (ничего не напоминает) соответственно - задайте себе вопрос достигнута цель: Учета товаров переданных контрагенту или нет. Каков критерий измерения достижения цели?
Или задайте вопрос, а зачем учитывать товары переданные контрагенту, каков интерес?

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

3754

Примеры / Re: Создание моделей вариантов использования

« : 31 Октября 2008, 13:50:47 »

1. Как Вы понимаете существуют разные уровни рассмотрения вариантов использования и область контекста.
2. ВИ не декомпозируются - это будет неправильно, но можно декомпозировать цели
3. Естественно начинать сверху вниз от целей бизнеса к целям пользователей
4. Естественным инструментом декомпозии в UML является пакет
5. Подсистема разбивается еще на ряд подсистем, задач, модулей, компонентов
6. Для каждого такого деления выстраивается модель взаимодействия, которая включает описание ВИ, причем диаграмма тут имеет последнее значение
7. Вариант использование - это элементарный бизнес-процесс производимый одним человеком в одном месте за один сеанс деятелности и приводящий к ощутимому результату, изменению состояния системы
8. ВИ описывает потребную с точки зрения пользователй функциональность системы
9. Логика работы такой функциональности может описываться диаграммами деятельности в первую очередь, а такжде системными диаграммами последовательностей во вторую

Кстати документо оборот лучше описыать с помощью DFD имхо

3755

UML SysML и пр. / Re: Вопросы по UML для сертификации

« : 30 Октября 2008, 01:11:36 »

Умница

3756

Управление Проектом / Re: Проектная документация при разработке на 1С:Предприятие 8.х

« : 29 Октября 2008, 23:15:20 »

Интересно, как подобные задачи другие решали.

Ага Мои слова вас уже притомили

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

А вы поищите темы на форуме, я и другие подобные темы поднимали.

Да с одной стороны есть инструмент со своими ограничениями, возможностями, +  и  -

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

Предполагается, что 1С обладает набором базовых понятий предметной области, из которых может быть составлено гибкое многообразие реальных задач.

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

Тогда надо иметь внятный документ базовых моделей 1С

Модель чего хотелось бы

Модель разницы

А?

3757

Sparx / Re: Enterprise Architect: Практика использования

« : 29 Октября 2008, 23:00:55 »

Спасибо. С Вашей презентацией я ознакомился. Но вопросов пока больше чем ответов.

Так и задавайте их! Прямо здесь

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

А причем тут модель и ЕА? Если Вы еще не понимаете как и что моделировать, то причем тут ЕА. К тому же лучше Вы выложите СВОЮ постановку и попробуйте выложить СВОИ модели. И толку будет больше, и ваши пробелы в знаниях и ваши незаданные вопросы будут очевидны

3758

Управление Проектом / Re: Проектная документация при разработке на 1С:Предприятие 8.х

« : 29 Октября 2008, 19:52:42 »

Задача - сделать максимально простую документацию, но достаточную для всех сторон Мне интересно каким образом документируются небольшие проекты в случае штатных разработчиков? Не пишется же отчет об обследовании, ведь работники сами прекрасно представляют организацию.. Как мне кажется: Надо просто задокументировать цели, пользовательские пожелания и задачи.

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

Такми образом можно набросать Видение и спецификацию дополнительных средств.

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

По сути Вы и сами все написали

3759

Управление Проектом / Re: Проектная документация при разработке на 1С:Предприятие 8.х

« : 28 Октября 2008, 22:39:33 »

Здравствуйте.

Особенности: взаимодействие с заказчиками складывается таким образом, что внедрение идет последовательно и разработка единого видения ИС/отчета об обследовании проблемотично.

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

Например: месяц пишем подсистему CRM, потом месяц подсистему "Управление инструментами" и т.д. Разработать общее ТЗ/документ требований и общую модель системы не возможно.

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

Вопрос: Раскажите, как такие работы оформляются у вас? Поделитесь опытом..

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

В общем формировали бизнес-процессы в BPMN - вполне понимаемые стороной заказчика, устраивали презентации и собрания.

Что касается стороны аналитик-разработчик, то тут проще - это внутренний мир и способ представления избирается привычный удобный. По своей схеме - по-моему - это нечто из советских времен, называемые постановками задачи: входная информация, выходная информация, предложения по экранным формам. Почти информационное обеспечение в внемашинным ИО и внутримашинным ИО .

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

3760

О Сайте и Форуме / Re: Скоро ДР сайта - подготовка

« : 24 Октября 2008, 16:32:58 »

Вы случайно не о Периодической системе визуальных методов?

3761

Системный Анализ и Требования / Re: Как правильно трассировать?

« : 22 Октября 2008, 22:59:03 »

Так все-таки трассировка - это прослеживаемость одно через другое, или же все-таки вытекание одного из другого. Если последнее - то, это, по-моему, и есть зависимость . Нет?

3762

О Сайте и Форуме / Re: Скоро ДР сайта - подготовка

« : 22 Октября 2008, 22:51:45 »

Очень интересно.

Денис удачи и вдохновения!

3763

Системный Анализ и Требования / Re: Как правильно трассировать?

« : 22 Октября 2008, 17:35:29 »

Я тоже вставлю свой алтын.

Трассировка или прослеживаемость. Происходить от английского trace III.
Среди переводов мы видим:
следовать, идти по следам
проследить, установить
прослеживаться, восходить

Такми образом прослеживаемость может быть разного направления как прямого, так и обратного.

Направление прослеживаемости можно понять относительно некоего требования или артефакта смотри вложение

3764

Реализация / Реализация шаблона MVC

« : 21 Октября 2008, 22:49:10 »

Я уже имел консультацию по этому вопросу. Мне было сказано, что я не понимаю назначение MVC, вполне возможно. Даже наверняка. Да нет же совершенно не знаю Но хочу знать.

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

Так вот возможно где-то что-то все-таки понимая, мне хотелось окончательно разобраться с применением MVC на практической задачки.

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

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

При авторизации:
Пользователь вводит логин и пароль
Система узнает пользователя, приветствует и предоставляет ему соответствующий доступ

Возможный сценарий реализации может выглядеть так:
1 Пользователь вводит url сайта в командную строку браузера.
2. браузер отображает Главную страницу сайта
3. Пользователь вводит логин и пароль в поля Формы авторизации и нажимает кнопку Войти
4. Браузер пользователя отправляет http- запрос, содержащий введенные значения логина и пароля, Web-серверу
5. Web-сервер перенаправляет запрос соответствующему Скрипту (по сути методу некоего класса-контроллера)
6. Класс-контроллер, выполняя метод, инстанцирует объект Пользователь с параметрами Логин и Пароль:
    если такой объект существует в БД, тогда запускается метод получить данные Клиента
    если такого объекта нема, создается сообщение-уведомление
7. Получив данные Класс-контроллер отправляет пользователю на браузер соотвествующую страницу сайта

Как полагаете пойдет такое?

Как это может выглядеть в виде некоего кода?

1. как я понимаю на action формы будет просто передача параметров нужному скрипту
2. в скрипте инстанциируется контроллер, который получает параметры и запускает метод, который
3. инстанциирует объект бизнес-логики, который
4  посылает запрос в БД
и в обратном порядке?

В общем чего не так? Не слишком все кудряво?

3765

Sparx / Re: Enterprise Architect: Трассировка требований

« : 21 Октября 2008, 19:01:58 »

Виталий, если не трудно, переведи на английский и я закину в поддержку. Пускай отрабатывают пока я имею право.

Хотя я тут поискал и кое что нашел.

К примеру у тебя есть модель требований -
1.выделяешь этот пакет
2. идешь в ProJect/Documentation
3. Там играешься Implementation Details или Dependences Details