1

Системный Анализ и Требования / Re: Оформление дополнительных требований к исходному ТЗ

« : 06 Июля 2012, 14:46:32 »

1. Желательно избежать ситуации, когда одновременно пересматривается состав компонент системы и их функционал (причем изменение этого функционала существенно затрагивает взаимодействие компонент) и при этом требования формируются и оформляются несколькими специалистами. Если сможете удачно декомпозировать систему на компоненты со стабильным функционалом их взаимодействия между собой, требования на систему в целом можно сформулировать в ТЗ, а требования к подсистемам детализировать/изменять в ЧТЗ.
2. Если система небольшая и требования формирует/документирует один человек - лучше требования вести в одном документе.
3. Актуализировать  ТЗ через дополнения к ТЗ (в виде отдельного документа) требует ГОСТ, это не всегда удобно. Если у вас нет жесткого требования следования ГОСТ - лучше вести версии ТЗ (если в word - файл в режиме "С исправлениями", в каждой версии которого приняты все исправления, кроме последних).

2

Методологии / Re: помогите отмахаться от ГОСТ 34

« : 29 Июня 2011, 23:30:10 »

В основе ГОСТ 34 лежит функциональная модель системы (функция: вход-выход, задача - функция или часть функции - уши IDEF0 торчат отовсюду), а UML изначально задумывался как обобщение нотаций, возникших для описания объектноориентированных моделей. Использовать UML при написании конкретного документа ГОСТ можно, сложно выдержать идеологию декомпозиции системы по ВИ, согласованное представление системы на бизнес- и системном уровне по набору документов ГОСТ. Поэтому некоторые методические проблемы ощущаются при попытке привлечь UML для описания функциональных моделей.
Где-то встречал информацию, что авторы UML cознательно не стремились предлагать средства для описания моделей, которые можно описать IDEF0.
Хотя народ придумывает как всё-таки приспособить UML для описания декомпозиции функций через activities/actions.

3

Системный Анализ и Требования / Re: Описание требований. Много документов или один

« : 23 Февраля 2011, 15:09:29 »

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

В тексте приводится определение "Фича - небольшая часть функции в форме <действие> <результат> <объект>, с результатом, имеющим ценность с точки зрения клиента. Например - "рассчитать суммарный объем продаж" или "проверить пароль пользователя".

В смысле этого определения фича может иметь вид "заполнить <название поля> интерфейсной формы значением <название показателя>".

Из текста раздела Buid feature list следует, что система декомпозируется по иерархии:
 автоматизируемая область (домен) -> предметные области (subject areas) -> виды деятельности (business activities) -> список фич.
Причем каждой фиче соответствует действие (по крайней мере) одного из видов деятельности (activity).

4

Системный Анализ и Требования / Re: Описание требований. Много документов или один

« : 21 Февраля 2011, 14:05:31 »

нашел вот такую штуку: http://habrahabr.ru/blogs/webdev/70424/ посмотрю (английский текст занимает много времени.. хотя на русском я не нашел трудов, но пока ограничусь хабром).

Любопытный материал. Хотя там в основном обсуждается как описать технологический процесс разработки, какими разными диаграммами, и как этот процесс планировать.
К сожалению декомпозиция системы на относительно независимые элементы (предметы - subject areas)  в этом материале не упоминается (в отличие от материала в Википедии). Представление же системы стандартным набором диаграмм UML вряд ли можно рассматривать в качестве "изюминки" FDD.  А технология разработки/проектирования не дает ответа на сколько и каких подсистем или предметов декомпозировать систему.
В каждом конкретном случае декомпозиция получается исходя из специфики бизнеса и системно-технических решений/платформ. В Вашем случае можно посмотреть на уже работающую систему, как она де-факто декомпозируется по предметной области - возможно, по специализации работающих с ней пользователей или рынкам: например, операции на вторичном рынке и первичное размещению ценных бумаг - достаточно разные виды деятельности, возможно в Вашей системе интерфейсные формы и объекты базы данных могут быть отнесены к относительно изолированным ВИ/компоненты/подсистемы по этим видам деятельности (или как-то иначе).

5

Системный Анализ и Требования / Re: Описание требований. Много документов или один

« : 20 Февраля 2011, 20:23:19 »

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

В feature driven development (FDD), которая рассматривает доменную модель в качестве одного из основных артефактов, эта модель как раз используется для декомпозиции всей области на предметы (subject areas). Тоже способ декомпозиции.

6

Системный Анализ и Требования / Re: Описание требований. Много документов или один

« : 20 Февраля 2011, 15:16:45 »

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

Вы уже, кажется, описывали этот проект здесь  в ответах 17 и 19 на форуме. Немного странно показалось, что описание структуры данных хранилось в "файле атрибутов". Использовалась ли в проекте диаграмма(ы) классов (с отображением на ней показателей, которые надо отображать в интерфейсе)?

Только вот всё равно волнует - один документ или много...?

Вряд ли можно дать ответ на этот вопрос до решения, как именно (и на что) декомпозируется система. Иначе есть риск написать полтора документа на две с половиной подсистемы .

7

Системный Анализ и Требования / Re: Описание требований. Много документов или один

« : 19 Февраля 2011, 13:45:50 »

Shur, спасибо большое за развернутый ответ и пищу для размышлений. Один нюанс - предаставитель заказчика отчасти выступал как БА, то есть он формулировал свой бизнес процесс, но ещё и интересовался СА - сам, например, описывал формулы расчета некоторых полей.
Не могу сказать, что проект был не по ГОСТу...

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

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

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

Вы, наверное, знакомы с методологией SADT, IDEF0? Требования к документам ГОСТ очень удобно воспринимать под углом зрения этой методологии и соответствующей нотации. Единственно, что ГОСТ не выделяет явно входы "управление" и "ресурсы". Принципиально важно исходить из того, что функция задается описанием входов и выходов (с указанием соответствия выходов выходам). "Задача" по ГОСТ - это функция или часть функции. А документ "Описание постановки задачи" как раз предполагает описание этих входов и выходов, его можно использовать для того, чтобы расписать каждую функцию из ТЗ.

Если Вы имеете в виду под разработкой реализацию системы в коде, то важно учитывать, что методологию SADT изначально не предполагалось использовать для низкоуровневого описания системы. Авторы самой известной книги по SADT "МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ" Дэвид А. Марка и Клемент МакГоуэн писали во введении к книге:

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

Поскольку методология SADT создавалась в 60-80-е годы и предназначалась для описания системы на бизнес-уровне, она не учитывает особенности современных средств программной реализации. ГОСТ 34 (да и ГОСТ 19) - стандарты эпохи SADT, в силу этого не очень приспособлены, да, видимо, и не предназначались для описания  детальных требований к программной реализации (разработке) системы, что может создавать проблемы при проектировании системы с использованием SADT.

Например, IDEF0 предполагает, что выход и выход системы - это "данные", "сигналы". Причем на выходе и выходе - разные данные. Если же (на бизнес уровне) на входе и выходе одни и те же объекты (системный уровень), но в разных состояниях, то получается скорее диаграмма состояний, которую лучше тогда рисовать с использованием соответствующей нотации (например, в UML).
Описание с помощью ВИ функциональных требований к системе, разрабатываемой в объектной парадигме,  проблемы такого рода снимает, поскольку концепция use cases развивалсь в рамках ООП и акцентирует ИМХО скорее процесс, алгоритм, а не входы и выходы (с оговоркой важности указания предусловия и постусловия ВИ и наличия полезного для пользователя результата ВИ).

8

Системный Анализ и Требования / Re: Описание требований. Много документов или один

« : 17 Февраля 2011, 16:55:28 »

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

Важно различать проблемы:
*декомпозиции системы и декомпозиции документа.
*совмещения в одном документе описания требований Заказчика и постановок на их реализацию для разработчика.

О декомпозиции

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

Техническое задание по ГОСТ подразумевают один вид моделей системы, RUP - другую.
ГОСТ предполагает декомпозицию системы на подсистемы, которые могут снова декомпозироваться на подсистемы. Предполагается также, что можно сформулировать требования к функциям (результатам работы) системы и описать как функции системы декомпозируются на функции подсистем. Такое верхнеуровневое описание должно объяснять (Заказчику обязательно) каким образом через функциональное взаимодействие подсистем будет получен результат работы (выполняться функции и задачи) системы в целом. Если подсистем нет - то как декомпозиция функций системы на задачи (комплексы задач) обеспечивает достижение необходимого результата. Описание декомпозиции системы на подсистемы и функций на задачи должна давать представление о системе, которое является основой для формулировки требований и составления ТЗ. 

Попытка описать в рамках ГОСТ систему, реализуемую в объектной модели,  вынуждает пускаться в достаточно вольные интерпретации требований ГОСТ, "натягивать" объектные представления на IDEF0-образные функциональные модели, изобретать способы отражения различных уровней представления системы в документах, для этого не приспособленных.

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

О декомпозиции при объектном подходе

Исторически так сложилось, что бизнес, как правило, мыслит в терминах функциональной модели, а разработка ведется в объектных подходах. Ориентированные на RUP и UML методологии (см.например, G.Overgaard, UML blueprints),  предполагают декомпозицию системы, прежде всего по вариантам использования. Декомпозиция по документам для Заказчика, по идее, может идти по вариантам использования. Но опять же, пока мы описываем систему в терминах вариантов использования. Если же мы начинаем рисовать диаграмму классов системы, причем на уровне, необходимом разработчикам системы, то её декомпозиция (особенно по вариантам использования) и поддержание её в консистентом и актуальном виде представляется вообще весьма трудоемкой и даже проблематичной задачей.

Опять же касательно совмещения требований и постановок:
Стоит ли включать детальные требования в ТЗ для Заказчика? Стоит ли вообще пытаться оформлять детальные требования (постановки) в рамках объектного подхода в виде официального документа - ведь не на зря были предложены Agile-подходы ?

В каком случае мы можем работать с одним документом? Такая ситуация может возникнуть, если над проектом работает один аналитик, а так же один или множество заказчиков. При работе с множеством заказчиков в одном документе потребуется хорошо планировать работу, чтобы проверку требований и реализации заказчики осуществляли поочередно. Это очень тяжело, так что я всегда вел требования каждого заказчика в отдельном документе, а после согласований их объединял. В данном случае, если заказчиков множество, то придётся распараллелить их работу по согласованию документа, что скажется на сроках проекта.

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

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

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

Если заказчик настаивает, что это новый проект и он не хочет подписывать новое ТЗ (постановки на реализацию), а вести только изменения на каждый элемент интерфейса, то тогда, при написании новых документов или правке каждый аналитик будет готовить список новых полей и измененных, а так же новые документы. Потом переносить это в один сводный документ и опять подписывать. Лишняя работа у нас будет по переносу новой информации. Как входной материал можно использовать не весь документ, а сразу браться за доки, которые мы мержили для подписи. Очевидная проблема - как писать формулы, если часть нумерации в старом ТЗ, а часть в новом (лазить туда-сюда и давать ссылки на старый док, чтобы показать заказчику, а потом сносить в общий ексельник, актуальный по системе).
В любом случае, самый лучший вариант - все поля вывести в отдельный Excel-файл, соблюдать там единую нумерацию (с этим не должно быть трудностей), апдейтить маленькие доки, а новые объекты вносить под новыми последующими номерами.

В описанной ситуации угадывается практика ведения документов по ГОСТ в режиме изменения. Если у Вас поехала нумерация (даже страниц) заменяете весь текст начиная с первого изменения в режиме "Лист 23-54 заменить на прилагаемые листы 23-54" "Добавить новые листы 55-57" если количество листов увеличилось или "Изъять листы 55-57", если количество листов уменьшилось. Описываете это в извещении на изменении (Excel ГОСТом не предусмотрен:) с общим указанием, что именно изменили в документе (3-5 предложений).

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

9

Управление Проектом / Re: Особенности работы с госзаказчиками

« : 11 Февраля 2011, 19:37:18 »

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

Ситуация такова:
1. формальная документация и реальное состояние продукта друг друг не соответствуют и соответствовать никогда не будут.

Пожалуйста, уточните:
1. Есть реальный продукт с документацией и Вы его дорабатываете? Или ведется разработка с нуля нового, но аналогичного продукта?

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

2. Неофициальная документация - это требования к новому продукту (системе)?
2а.Если это попытка описать решения для старой системы, то зачем это описание решений вам необходимо и как вы реально это описание используете?

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

3. Вряд ли Вы всё-таки ведете разработку на основании требований, взятых совсем из собственной головы. Наверное, есть требования Заказчика в каком-то виде и наверное у Вас есть проблемы с их полнотой и детальностью? Есть ли возможность задавать уточняющие вопросы по требованиям Заказчику и получать ответы? Задокументированы ли эти требования хотя бы в каком-то виде (например ТЗ)? Подписан ли этот документ Заказчиком (возможно, в качестве приложения к договору)?

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

Личный опыт работы с госами особенно приветствуется

4. По первому предложению очень важно иметь согласованные с Заказчиком требования (подписанное Заказчиком ТЗ), которые не содержат невыполнимых с вашей стороны требований, но содержит все необходимые вам рамки и ограничения проекта, снижающие чрезмерные трудозатраты. Именно ТЗ, как правило, используется в качестве основного документа для "разбора полетов" на официальном уровне при совсем неблагоприятном развитии событий (постучим по дереву) и невозможности разрешить ситуацию в рамках договоренностей с Заказчиком.

10

Проектирование / Re: Проект по уму на VP

« : 05 Января 2011, 13:44:16 »

Последний вариант перечня ВИ, который Вы привели:

написать в блог
написать в сообщество
написать на форум
добавить свое фото
добавить файл
добавить объявление
написать новость
разместить статью
Пригласить друга

Какие у этого перечня недостатки (подразумевающие в каком направлении этот перечень стоит доработать) я изложил в сообщении 53 от 3 января. Посмотрите, пожалуйста. Если Вы не согласны с тем что я написал, укажите, пожалуйста пункт сообщения и с чем именно Вы не согласны. Какие конкретно затруднения есть у Вас с доработкой этого перечня ВИ?

11

Проектирование / Re: Проект по уму на VP

« : 05 Января 2011, 13:07:52 »

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

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

12

Проектирование / Re: Проект по уму на VP

« : 03 Января 2011, 21:22:31 »

В каком формате их нужно писать? Например, есть действие:

написать в блог
написать в сообщество
написать на форум
добавить свое фото
добавить файл
добавить объявление
написать новость
разместить статью
Пригласить друга

Дальше идет: "редактировать"
установить "формат доступа" и т.п.

Если Вы предполагаете в дальнейшем использовать UML, предлагаю придерживаться соответствующей терминологии. Вариант использования может реализовываться выполнением последовательности действий. Т.е. "вариант использования" - это одно, а "действие" - это совсем другое.

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

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

3. Вопрос, какие специфические требования к способам обмена информацией предъявляет тот факт, что этот обмен осуществляется пчеловодами, конечно остается. Я охотно присоединяюсь к вопросам, которые Вам задал Galogen, но я предполагал, что можно вернуться к ним после того, как получим относительно формализованное описание системы as is  (как она видится Вам, как создателю системы), поскольку такая задача была заявлена в сообщении № 28.
Если Вы можете ответить на вопросы, которые Вам задал Galogen, ответьте, пожалуйста. В любом случае без ответа на них Вам сложно будет обосновать планируемые доработки системы (для обсуждения видения системы to be).

13

Проектирование / Re: Проект по уму на VP

« : 03 Января 2011, 15:37:02 »

Вы правы.
И способов гораздо больше.
Я надеюсь, понятно изложил суть проекта ;-)

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

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

14

Проектирование / Re: Проект по уму на VP

« : 03 Января 2011, 14:57:03 »

Билайф.орг - информативнее - на нем собрана основная (возможная) информация о пчеловодстве, пчеловодах. Цель билайф. орг - ОБМЕН ИНФОРМАЦИЕЙ а не "ОБЩЕНИЕ" именно по-этому, СООБЩЕНИЕ является отправной точкой.

Можно пока зафиксировать: поскольку сообщение является отправной точкой, а не конечной, отправка сообщения не является целью системы. В качестве цели полагается "обмен информацией". Правда, не совсем понятно, почему отправка сообщения и чтение ответов на форуме  Вы не считаете обменом информацией?
Может быть Вы хотите предоставить пользователям возможность обмена информацией различными способами в рамках одного сайта? Т.е. чтобы  пользователь мог выбрать наиболее подходящий ему способ структурирования/модерирования информационного обмена и выбрать,
завести ли собственный блог, завести тему в форуме или прислать администратору сайта статью для опубликования (возможно, после редактирования администратором/редактором сайта)?
У Вас уже сейчас есть разделы: статьи/новости, блоги, форум и даже чат. Т.е. цель (назначение) системы - предоставить пользователям возможность обмена информацией (четырьмя?) разными способами в рамках одного сайта?

15

Проектирование / Re: Проект по уму на VP

« : 03 Января 2011, 12:11:35 »

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

К сожалению, из Ваших ответов остается неясным - зачем Вы создали и развиваете сайт по теме "пчеловодство"? Ради пчеловодов или ради программы-движка сайта как таковой? Если вы заинтересованы в том, чтобы предоставить пчеловодам возможность создавать сообщения и получать на них ответы, то почему бы просто не адресовать их на форум сайта "Пчеловод.инфо"?
Зачем тратить время на создание/поддержку сайта, основная цель которого предоставить пчеловодам возможность, которую они и так уже имеют?