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

×


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

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


Сообщения - Сергей()

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 »
106
Без описания того, кто и как будет использовать эту схему, обсуждать её правильность или неправильность можно долго.

Представьте вопрос «Я нарисовал схему дома, что в ней не так»? Приходит водопроводчик, видит одно, электронщик — другое, архитектор — третье, дизайнер по интерьеру — четвёртое.

Зачем понадобилась диаграмма? Кто и какие действия будет с ней совершать? В каком случае качество диаграммы будет считаться удовлетворительным, если она позволит делать что и с какими условиями?

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

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

107
Когда меня просят о сводной схеме, я использую вложенные блоки. Обычно это снимает вопрос и чиновникам в целом становится понятно что к чему.
Понятно же что такой запрос связан с желанием все узнать из одной-двух схем, а не читать многостраничный текст )
Советую нарисовать статичную схему без связей.
Интересная идея с вложенными блоками, попробую.
Блок более высокого уровня по смыслу представляет собой что? Группировку блоков нижележащего уровня? Или их абстракцию?

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

Но если говорить о UML то...
В принципе наверное можно использовать трассировку для связи элементов из разных моделей.
Только не понятно на какой диаграмме такую трассировку можно отобразить

Кстати, вы действительно рассчитываете, что те, кто запрашивает одну сводную схему знают что такое "композиция", которая показана на диаграмме?
Будьте проще. Нет в нотации UML инструмента "все и сразу", зато он есть за ее пределами  )
Скорее, это я рисовал для себя.
Заказчик, думаю, не обратит внимания на разницу между типами связей. Или поймет после краткого объяснения.

108
Предлагаю ознакомиться с книгой "UML2 и унифицированный процесс" Джима Арлоу и Айлы Нейштадт.
Скачал, буду изучать.
При беглом просмотре обратил внимание на главу "5.7.3. Избегайте функциональной декомпозиции",
что косвенно подтверждает что для моей схемы использовать Use Case diagram не совсем верно.

Коль уж измеряем слонов попугаями, по-моему как-то таг:
1) Use-case diagram
2) Интерфейс - User interface diagram
Все, что связано с функциями, должно иметь приставку типа "система должна..." - тут подойдет Requirements Diagram.
Ну и не забываем про трассировки между интерфейсом, требованиями и вариантами использования. И не стоит все элементы держать в одном пакете - старайтесь каждую диаграмму с элементами поместить в отдельный пакет и отобразить взаимосвязь между пакетами на Package Diagram.
Вы все правильно поняли, но хотелось это все изобразить на одной сводной схеме.
Это возможно?

И еще... Я схему делаю в PowerDesigner-е, в нем нету Requirements Diagram :(

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

Раздел "Веб-интерфейс" - это про сайт или про API? Если про сайт, то его лучше бы представить в виде иерархической структуры страниц сайта. Или не иерархической.
Веб-интерфейс - это про сайт. То есть в этом разделе представлены основные функциональные разделы сайта, точнее их первые страницы.
Структуру страниц представить на этой схеме будет нереально. Так как во-первых страниц очень много, сайт большой. Во-вторых, это противоречит духу этой схемы, ведь на схеме нужно отобразить только "главное".

Продолжая первый пункт ответа, возникает вопрос: можно ли элементы раздела "Интерфейс" представить на этой схеме при помощи ВИ?
Чем являются "Личный кабинет", "Административный интерфейс"?
Можно ли их считать функциями? целями?

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

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

Очень большое внимание уделено процедурам регистрации. Имеется в виду регистрация в каких-то гос. органах?
Нет, это просто регистрация на сайте торгов, чтобы иметь возможность использовать функциональность сайта.
Вся процедура регистрации состоит из трех шагов.
Сначала пользователь просто регистрируется (первичная регистрация) - ему предоставляется личный кабинет, но торги он проводить не может.
Затем он регистрируется в качестве организатора и\или участника, и после этого получает возможность запускать новые торги и\или участвовать в торгах.

110
огромное спасибо за ваши замечания,
далее отвечаю на возникшие вопросы

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

Я подготовил такую схему, но чувствую что она не вполне корректна.
Хромает терминология.

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

112
Я бы добавил user stories в раздел Требования к Системе в подраздел Требования к функциональным характеристикам.

понятно, спасибо за помощь

113
Я чувствую, следующим Вашим топиком будет "Организация N желает подешевле "написать" проект Постановления Правительства. :)
Да, тенденция такая имеется :)

Оно Вам надо?
А куда деваться?  :(

Первый совет ...
Второй ...
Спасибо за дельные советы.
Буду искать указанную информацию и ... собирать грабли.

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


114
Вы знаете эти показатели? Если да, то почему бы не написать...

Как я понимаю, надо описать целую систему, не только показатели.
Например: 1) должностные лица, подразделения участвующие в контроле, их полномочия; 2) система регистрации показателей; 3) потоки информации о контролируемых показателях: кто, когда и кому передает; 4) кто проводит анализ показателей и принимает решения о необходимых мерах; 5) процедуры контроля: регулярность и т.д.

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

Помогите разобраться с написанием этого документа.

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

Может быть у кого-нибудь образец есть?

Поиском в интернете нашел много информации по внутреннему контролю.
Но он касается только финансовой деятельности организации.

В общем подскажите, пожалуйста, направление - куда двигаться, что искать, о чем писать?

116
...
В официальное ТЗ надо вставить нечто чужеродное, что имеет тенденцию часто меняться. Зачем надо -  я обсуждать не готов, вот такая забористая дурь в команде автора. Что реально могу - ответить автору на его вопрос "куда вставить последнюю..." так, чтобы потом не было мучительно больно. ...
спасибо за понимание :)

117
Прошу тогда еще обсудить следующий вопрос, на который мы не обратили внимания.
Пользовательские истории имеют отношение к системе в целом, или к программному обеспечению системы?

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

Что думаете?

118
ОК, я все понял, спасибо

119
По 34 ГОСТу перед ТЗ есть ещё 2 этапа:
1. Формирование требований к АС
2. Разработка концепции АС
http://standards.narod.ru/gosts/gost34/34-601-90.htm

имхо пользовательские истории более уместны в отчете по первому этапу (формирование требований), чем в ТЗ. Как вариант решения, если просто хочется "чтобы было по ГОСТу", создайте этот отчёт. Там много пересечений с ТЗ, требования к содержанию отчета есть здесь: http://standards.narod.ru/gosts/gost34/50-34698-90.htm, приложение 1.

Да, мы в курсе про этап формирования требований.
Но дело в том, что не просто " хочется чтобы было по ГОСТу", а чтобы было как я написал в исходном вопросе: чтобы ПИ были добавлены в ТЗ.

Мы все время уходим от моего главного вопроса, пытаемся его обойти.
Я попросил высказать свои мнения о том, в какое место ТЗ лучше всего вставить ПИ с учетом логики изложения ТЗ и особенностей ПИ.
Я предложил добавить новый раздел между разделом "3. Характеристика объекта автоматизации" и разделом "4. Требования к системе".
Есть лучший вариант?

Еще остался вопрос: могут ли пользовательские истории иметь отношение не к системе в целом, а к какой-то ее части?

Ну и еще появился вопрос чисто по формулировке ПИ - но это лучше в отдельной теме обсудить

120
Что, реально заказчик и ПМ будут садиться и сверять списки из 120 user stories и 50 ФТ между собой? Им больше заняться нечем?

А разве user stories и ФТ не должны быть согласованы между собой когда они находятся в разных документах?
Кто-то же их сверяет.
И какая тогда принципиальная разница с тем, если они находятся в одном документе?

А разве другие части ТЗ не должны быть согласованы между собой?
Да и не только ТЗ...
В проекте много документации, и все документы должны быть согласованы друг с другом.
Кто-то же сидит и читает все это и при обнаружении разногласий - исправляют.
Им - этим "читателям" проектной документации - получается тоже больше заняться нечем?

Почему же нельзя сделать проверку того, что ФТ учитывают все что было описано в ПИ?

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 »