3856

Обучение / Re: [Приемы и Методы Анализа] Преамбула

« : 14 Сентября 2008, 21:14:55 »

"A trade study or trade-off study

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

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

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

3857

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

« : 13 Сентября 2008, 23:13:50 »

LastDragon, спасибо за помощь и Ваш вклад.

3858

Обучение / Re: Дисциплина "Управление данными"

« : 13 Сентября 2008, 23:00:48 »

Рискую надоесть, но все же.

Ну что Вы, Виктор. Отличное подспорие. Причем от человека, который гораздо больше меня в этом работает и понимает.
Тем более что если я и знаю определенные теоретические основы и практику, то все-таки не в таком систематическом виде.
Хотя я активно использовал книгу Крёнке, но я заострял в своем курсе Теория информационных процессов и систем внимание на моделировании, а не практическом использовании моделей. Физику вообще не трогал, оставляя это будущим курсам других преподавателей.
Книгу Третий манифест имею, читал с удовольствием.

За ссылку большое спасибо. Полезно, интересно, бережет время

3859

Обучение / Re: [Приемы и Методы Анализа] Преамбула

« : 13 Сентября 2008, 22:43:17 »

- trade study? (не знаю этот термин по-русски)

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

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

ссылки дать к сожалению не могу. Хотя можно просто поискать в инете
http://www.elitarium.ru/2004/07/08/zakon_pareto_ili_princip_8020.html
http://ru.wikipedia.org/wiki/Закон_парето
http://pocketnotes.ru/2008/01/12/pareto-part-2/
http://arbuz.uz/t_pareto.html
http://shkolazhizni.ru/archive/0/n-12010/
http://www.triz.org.ua/data/c83.htm
http://www.dist-cons.ru/modules/uv/Time3/text3_3.html
и т.д.
[/quote]

3860

Конференции Семинары и Тренинги / Re: [Семинар] Техника Вариантов Использования, 11 октября, Спб

« : 12 Сентября 2008, 19:02:18 »

и как всегда с ошибкой утреслась это от какого корня? треска?

3861

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

« : 12 Сентября 2008, 13:28:28 »

хорошо

3862

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

« : 12 Сентября 2008, 13:17:23 »

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

Вопрсо можно интерпретировать по-разному, что Вы имеете в виду в данном случае.
Где Вам нужно добавить новый тип даннных? Если задать тип данных атрибута - тогда добавляйте атрибут и задавайте ему тип данных. Если же Вы что-то другое предполагаете, поясните

3863

Обучение / Re: [Приемы и Методы Анализа] Список

« : 12 Сентября 2008, 09:43:59 »

- mind map
- диаграммы Ишикавы
- принцип Парето
- анализ по шаблонам
- деревья или таблицы решений
- морфологический ящик
- экспертные оценки
- ...

3864

Обучение / [Приемы и Методы Анализа] Преамбула

« : 12 Сентября 2008, 09:38:17 »

Ожидаемый результат: методика преподавания анализа и развития аналитических способностей.

Цель: обеспечить устойчивые навыки применения приемов и методов анализа при разработки ПО и ИС у большей части обучающихся.

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

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

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

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

3865

Конференции Семинары и Тренинги / Re: [Семинар] Техника Вариантов Использования, 4 или 11 октября, Спб

« : 11 Сентября 2008, 20:28:03 »

А смысл его брать, если он и так есть?? Мы хотели разобрать новый пример прямо с аудиторией.

Это ты зря - ты можешь его использовать как отправную точку.

Ну если те все равно - так примеров море же.

От похода в магазин до оформления кредита. От получения зачетов до организации чата

3866

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

« : 11 Сентября 2008, 20:25:34 »

Эд, и я бы ничего не понял из такого описания требований ....
1. Вовсе не обязательно писать именно юзкейсы -- пиши просто сценарий или уж если юзкейсы, то в casual формате по Коберну.

можно

2. Разделять на типы на типы можно только в том случае, если у тебя есть согласованный со всеми для данного проекта Requirements Management Plan, в котором будет расписано все про типы требований. Если в культуре компании нет такого -- лучше не делать, особенно если до этого не было евангелизма на эту тему.

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

3. Нафиг писать в виде отдельных требований типы данных (целое число, дата от 1 до 30 ... кстати а 31 числа не бывает?)? Это можно спокойно отдельно написать в словаре данных.

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

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

Он это и имеет на входе в качестве контекста. Далее аналитик прикладывает правила, по которым формируется тот или иной документ при наличии тех или иных исключений.


Резюме.
Типы не важны сначала нужно покреститься. Окей.

Все велью в ответе нет. Вернее сказано не понятно. Окей как будет понятно?

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

Happy birth day, Yury

3867

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

« : 11 Сентября 2008, 17:16:12 »

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

Ранее используемый формат не устраивает. Решили работать по науке.

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

Сразу возникла проблема:
а/ формы представления требований
б/ способы добавления решений
с/ разделение труда

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

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

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

Хотя может так можно? Ведь требование пишется в конечном счете для программистов?

Поскольку пока форма не принята, задался вопросом, а как корректно писать требования.

Предложил такой подход.

Анализируя задачу смотрим на что в конечном итоге это должно влиять:
1. на форму счетов и расходных документов
2. на порядок и сроки их создания

Потому я предложил двигаться от конечного результата, типа.
1. Скидка по предоплате
  система должна обеспечивать возможность указания режима использования скидки по предоплате
  1.1. Величина скидки по предоплате - целое не отрицательное число
  1.2  Скидка действует до даты Х
        1.2.1 Дата Х - целое не отрицательное число в диапазоне от 1 до 30
  1.3 Скидка является внесубъектным свойством, т.е. задается один раз и распростарняется на все субъекты учета
  1.4 При формировании счетов указывается цена со скидкой для всех клиентов
2. Формирование счет-фактур и актов
   2.1 Есть фиксированная цена
         Для клиента с фиксированной ценой скидка по предоплате не применяется
   2.2 Есть задолженность
         Для клиента с задолженность скидка не применяется
   2.3 Оплата в срок
        При оплате до указанного срока (1.2.1) документы формируются со скидкой
        2.3.1 Оплата не полная
                Если опалте сделано в срок но не полностью, скидка не применяется и указывается долг клиента
        2.3.2 Оплата не в срок
                Если оплате не выполнена или выполнена после срока, скидка не применяется и указывается долг клиента

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

При этом данная структура загоняется в RaQuest или EA и формируется диаграмма для более наглядного представления и анализа согласованности...

Итак вопросы
1. Форма описания требований?
2. Следует ли разделять требования?
3. Что должен содержать документ, т.е. что понимать под спецификацией требований? (для заказчика документ не пишется и у заказчика соответственно не подписывается)
4.Не следует ли иметь то что есть и показать во что нужно изменить?
5. Как лучше группировать требования и выстраивать зависимости?
6. Следует ли предлагать ГУИ прототипы в качестве требований или их оставить для проектировщиков?
7. Что следует вносить в документ аналитику, а что проектировщику?

Может еще, что добавится после....

 

3868

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

« : 11 Сентября 2008, 13:49:25 »

Англоязыруй свой запрос и мне на ящик кидай, перешлю в службу поддержки

Версию mysql, кодовая страница, общая настройка, версия билда ЕА. Текст твоих действий. Попробуй и на других вариантах для солидности.

3869

Конференции Семинары и Тренинги / Re: [Семинар] Техника Вариантов Использования, 4 или 11 октября, Спб

« : 11 Сентября 2008, 13:46:40 »

Возьми пример из Вигерса. Если чуток доработать и кое-что выкинуть и объединить - то что нужно.

Система заказов в кафетерии.
1. Прописан Образ
2. Прописан список ВИ (хотя можно его скорректировать)
3. Есть описание 3 ВИ
4. Есть список бизнес-правил
5. Есть ТЗ для одной из функций

3870

Для всех / Re: Создание АРМ-врача

« : 10 Сентября 2008, 08:54:46 »

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

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

Примеров эффективного примениния наверняка не мало. Как минимум посмотрите книгу Проектирование баз данных с помощью UML/ Нейбург Э.Дж., ​Максимчук Р.А

Да и собственно сама предметная область тут не имеет значение. Главное, что система имеет пользователя, у пользователя есть набор профессиональных задач, которые Вы хотите заложить в АРМ. Это приводит Вас к применению вариантов использования. Очевидно, Вы будете делать ОО систему, а следовательно это приводит Вас к диаграмме классов, из которой последовательно выводится структура БД и архитектура приложения.