16

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

« : 28 Декабря 2010, 16:57:32 »

Да, указанный перечень - это перечень ВИ системы, пользователями и гостями сайта

Хорошо. Не могли бы Вы пояснить, как ВИ системы связаны с целевой тематикой сайта (пчелы, пчеловодство)?
Почему это важно:
Обычно цели системы определяют предлагаемые для достижения цели решения. И предлагаемые решения ограничиваются рамками поставленных целей: функциональность выходящая за пределы установленных целями границ - это, как правило, усложнение системы, увеличение затрат (ваших сил и времени прежде всего) на её разработку. При попытке создать излишне универсальную систему может оказаться, что система разработана под "неправильные цели" и не нужна, неудобна пользователям.
     
1. Пока не видно причин, почему социальная сеть с таким перечнем ВИ не сможет объединить и автолюбителей и пользователей сотовой сети "Билайн" и в принципе - кого угодно.
Создание универсального "движка" для сайта социальной сети в принципе может представлять самостоятельную ценность (если сможете конкурировать с ЖЖ, Цукербергом . В этом смысле может быть Ваша цель на самом деле - создание универсального движка-сайта социальной сети? Тогда заявленный Вами перечень ВИ можно рассматривать как ВИ верхнего уровня ("уровня цели").

2. Если же для Вас важно, что этот сайт именно для пчеловодов, не могли бы Вы пояснить, зачем пчеловодам нужна социальная сеть:
* Чем она лучше, например, журнала "Пчеловодство" , или ЖЖ?
* Насколько востребованы пчеловодами функции общения пользователей сайта, специфические для социальных сетей? Может быть сообщество пчеловодов больше заинтересовано не сколько в том, чтобы общаться между собой, формировать группы/клубы, сколько распространять информацию вне сообщества?
* Зачем на сайте размещается информация по растениеводству, разведению кур? Почему Вы указываете только пчеловодство в качестве  главного ориентира, тематики сайта?


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

17

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

« : 28 Декабря 2010, 13:46:12 »

Да, все так и есть - именно этот перечень сейчас существует!

Извините, не могу считать это ответом на свой вопрос. Вопрос был не про существование перечня, а про то что, считаете ли Вы этот перечень перечнем вариантов использования системы?

18

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

« : 28 Декабря 2010, 11:46:05 »

Это минимальный перечень, так сказать отправная точка с которой все начинается.

Но Вы готовы рассматривать этот перечень именно как перечень вариантов использования системы?

19

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

« : 28 Декабря 2010, 11:23:34 »

Да, В указанном перечне (Ответ #32) все актуально

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

20

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

« : 28 Декабря 2010, 10:54:23 »

Вот вот!
Я не знаю с чего начать и как лучше все описывать! Вы правы! Что можете посоветовать?

Предложение "с чего начать" содержится в моем сообщении от 25 декабря, причем Вы сами совершенно верно ранее предложили этот способ действия, и Вы даже сделали шаг в предложенном направлении. Не понимаю, почему вы делаете шаг назад и снова поднимаете вопрос про то "с чего начать"?
Могу посоветовать Вам ответить все таки на вопрос, который я Вам задал 26 декабря: можем ли мы принять в качестве перечня ВИ для Вашей системы то, что вы описали в сообщении от 25 декабря. Если Вы считаете, что этот перечень актуален, можно двигаться дальше. Если Вас что-то смущает в этом перечне, то что конкретно?

21

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

« : 27 Декабря 2010, 21:44:05 »

В общих чертах - все именно так. Но, если учитывать специфику системы - то каждый ВИ будет делиться еще на "множество" определяемое "по ходу" и в дальнейшем, я должен определить, какие более важные функции, а какие менее важные.
Сейчас задача состоит в том, чтобы понять "с чего начать" проектировать, а также - как избавиться от http://www.uml2.ru/forum/index.php?action=dlattach;topic=2493.0;attach=2832;image - этой назойливой проблемы.

Как-то Вы странно ответили: из вашего ответа всё-таки неясно, какой набор ВИ (что именно "всё...так"?) актуален - в Вашем ответе от 25 декабря или на диаграммах в более ранних сообщениях? Это важно, потому что дальнейшее проектирование системы предполагает декомпозицию  ВИ на ВИ (не функции!) более низкого уровня. Если Вы не определитесь с изначальным набором ВИ, неясно будет, что именно декомпозировать.

22

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

« : 26 Декабря 2010, 14:58:31 »

Правильно ли я понимаю, что система реализует следующие основные ВИ?

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

Или Вы полагаете для этой системы другие ВИ, которые Вы представили на прикрепленных ранее к Вашим сообщениям ДВИ?

23

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

« : 25 Декабря 2010, 16:19:09 »

Именно так. Вот первая задача - это просто "Описать систему as is"
а уже вторая - поставить задачу программисту

Кстати сказать, даже не знаю с чего начать описывать систему. Вот, сайт www .beelife .org
Есть программа VP 5

Для описания уже работающей системы можно идти от замысла и истории её создания.  Создатели системы, которую Вы собираетесь описать, должны были действовать в соответствии с рекомендациями Вашего сообщения №17 от 16 июня.

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

Если системы создана, значит так или иначе эта задача была решена. Пользователи, кому адресован сайт, на сайте перечислены: "менеджеры по продажам, руководители компаний, студенты, фермеры, пчеловоды...".
Сайт создан, значит можно исходить из того, что создатели сайта поняли, в чем состоят "пожелания пользователей" (Вы можете их назвать?) и "какие действия пользователи хотят автоматизировать" (Вы можете их назвать?).
Пожалуйста, напишите (текст не больше странички), что, как полагали создатели сайта, хотят пользователи (но именно пользователи, которым сайт адресован) и какие их действия предполагалось автоматизировать (но действия именно этих пользователей, а не, скажем, действия случайно попавших на сайт врачей или сантехников). 

24

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

« : 23 Декабря 2010, 11:28:39 »

Minona, уточниите, пожалуйста - Вам необходимо:
1. Описать систему as is (вы писали: "...зафиксировать все, что есть - записать в UML...")?
и/или
2. "...поставить задачу программисту?"  (описание системы "to be")


В зависимости от того, что требуется в первую очередь (1 или 2), выбирается и способ действия...

25

Идеи и мозговой штурм / Re: Любопытное ПО

« : 26 Ноября 2010, 12:09:33 »

Ну слава Меркурию, наконец-то мы выяснили, для чего все это нужно
Спасибо!

Так вот возвращаясь к PB - что нам дает знание того, как различные объекты (материальные и нематериальные) связаны друг с другом?

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

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

Применительно к  ИТ системам существуют характеристики связи между объектами и группами объектов: связанность- coupling и соединение- cohesion.

26

Термины и Определения / Re: [Термин] Протокол

« : 11 Августа 2010, 14:12:12 »

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

Описывает ли протокол алгоритм или алгоритм описывает протоколы зависит от рамок рассмотрения системы: протокол, может не содержать полного описания всех вариантов алгоритмов систем, созданных в соответствии с этим протоколом. Т.е. один протокол может описывать (задавать форматы и правила) множество допустимых алгоритмов. Представить в виде протокольного автомата все допустимые состояния класса объектов для конкретной системы (и всех допустимых для неё алгоритмов), видимо, можно всегда.

27

Бизнес-анализ и Целеполагание / Re: Что первично - цель или проблема?

« : 28 Июля 2010, 20:07:09 »

Хорошо. Давай уйдем из медицины, где мы ничерта не смыслим, в область деятельности предприятия. Как правило при орг изменениях, разработки ПО  и т.д. на предприятии смотрятся текущие проблемы и их как раз решают (ставят целью решение этих проблем в начале). Кстати, не факт, что от решения данной проблемы будет лучше всему предприятию. Но мало кто задумывается о том, что если мы решим эту данную проблему, то что потом? Искать новые проблемы, опять ставить новую маленькую цель и бежать до нее? Т.е. я предлагаю смотреть всегда чуть шире, не в рамках текущих проблем, а в рамках стратегических целей.

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

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

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

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

28

Бизнес-анализ и Целеполагание / Re: Что первично - цель или проблема?

« : 27 Июля 2010, 11:51:10 »

ИМХО взаимосвязь цели и проблемы, как правило, проявляется следующим образом:
1. Субъект формулирует новую или уточняет ранее поставленную цель
2. Разрабатывает план действий по достижению уточненной/разработанной цели.
3. Субъект действует в соответствии с планом и сталкивается с препятствием.
4. Субъект анализирует возникшую ситуацию и принимает решение о переходе к п.1 или п.2.

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

Интересно, что сам термин "проблема" этимологически связан с  понятием "проект".
Проблема - поздн. лат. problēma, из греч. πρόβλημα  «брошенное вперёд, поставленное впереди»; от προβάλλω  «кидать вперёд, выставлять перед собой; обвинять»; из προ- + βάλλω.

Проект - Происходит от лат. prōiectus (projectus) или prōiectum, прич. прош. от projicio  «бросаю, швыряю вперед», из pro- + jacio «бросаю». Русск. проект — начиная с Петра I; также в форме проэкт (уже у Шафирова, 1710 г.); вероятно, заимств. через нем. Рrоjеkt (с XVII в.).

Т.е. изначально, греческий "первоисточник" термина "проблема" акцентировал движение, действие - в противоположность некоторой статичности современного смысла термина. Для практики современного употребления термина "проблема" первоначальный смысл термина, связанный с движением, ценен тем, что обращает наше внимание на взаимосвязь  движения и "препятствия", преодоление которого требует возврата к анализу целей и способов их достижения.  Акцент на препятствии в определении, которое привела ida ИМХО весьма важен.

29

Для всех / Re: Построение диаграмм окружающей обстановки

« : 25 Марта 2010, 11:15:02 »

Мне надо декомозировать по функциональности.
Не знаю как описать средства отображения информации;управление обработкой ифнормации;восприятие информации об окружающей обстановке  в виде функциональной модели.
Еще такой вопрос как можно инормацию разделить на данные?

По вопросу "разделения информации на данные" предлагаю посмотреть: www.systems-thinking.org/dikw/dikw.htm

и еще: www.systems-thinking.org/kmgmt/kmgmt.htm

В последней ссылке есть следующее "разделение информации и данных" -
          o A collection of data is not information.
          o A collection of information is not knowledge.
          o A collection of knowledge is not wisdom.
          o A collection of wisdom is not truth.

30

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

« : 23 Марта 2010, 13:14:46 »

Можно выделить очень много вопросов, которые хотелось бы решать, приведу только примеры. 1. В прикладном проекте заявлено требование заказчика - сделать Х. Кто будет реализовывать это требование - команда фреймворка (с тем, чтобы Х вошло в функции платформы) или команда прикладного проекта? 2. Со стороны прикладного проекта П1 заявлено пожелание модифицировать фичу платформы Y. На какие характеристики прикладных систем в проектах П2, П3 и т.д. это может повлиять? 3. Во фреймворке есть фича Z, а в прикладном проекте мы ее докручиваем до Z*. Правильно иметь в прикладном проекте формулировку требований Z* или Z*-Z? Ну и т.п.

1. Отнесение реализуемого функционала к "платформенной" или к индивидуально настраиваемой части ИМХО относится к компетенции архитектора, архитектуре. Обсуждать эти вопросы в контексте управления проектами (планирование состава и графика работ, выбор архитектуры решения и пр.) стоит, когда уже артикулировано выделены варианты архитектурных решений (например, вариант 1 - с реализацией функционала целиком индивидуально только под данного заказачика, не трогая платформы. Вариант 2 - реализуем фичи 1, 2,3 доработкой платформы, 4,5,6 - индивидуально под заказчика). И выбор между вариантами принимать по критерию стоимости/сроки, а также сложности сопровождения продукта, после поставки его заказчику.
2. Возможность доработки функционала платформы под один проекта без создания проблем для другого проекта на этой же платформе можно обсуждать опять же только применительно к конкретной архитектуре платформы и архитектуры решений проектов 1 и 2.
3. Формулировка требований в прикладном проекте: если это требования Заказчика (ТЗ?) - неизбежно будут описаны требования к системе в целом (как то, что реализуются "платформой", так и то, что реализуется доработкой под Заказчика). Требования для разработчиков (скорее, уже описание проектного решения - техпроект) может ограничиваться описанием собственно дорабатываемого под данного Заказчика функционала (предполагая, что все команды разработчиков хорошо знают функционал "платформы") .

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