706

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

« : 06 Июня 2014, 23:03:26 »

Вот наткнулся на статью http://dis.ru/library/detail.php?ID=23311.

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

707

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

« : 06 Июня 2014, 22:35:38 »

Не понятно на счет стандарта. А РД IDEF0 2000? ://www.staratel.com/iso/IDEF/IDEF0/IDEF0Rus.pdf

IDEF- стандарт США, национальный. Немеждународный, если не обманываюсь. SADT методология. Стандарт основан на методологии. Но это не тождественные понятия. Я высказываю свое мнение. Естественно.

708

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

« : 06 Июня 2014, 20:33:46 »

Не уверен, что я доживу до дня, когда увижу "методологию творчества и созидательного начала" версии хотя бы 1.0.

Это не потянет? http://www.methodolog.ru/

709

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

« : 06 Июня 2014, 20:31:06 »

Но, следуя вашему призыву к конструктивному обсуждению, прошу уточнить, почему вы считаете, что SADT охватывает не только системный анализ. Какой документ, с вашей точки зрения, является эталонным описанием (стандартом) методологии SADT? Я, к сожалению, такого документа не знаю.

Structured Analysis and Design Technique - вот что такое SADT. Почитать можно тут: http://dit.isuct.ru/ivt/books/CASE/case8/sadt_index.htm
SADT - не является стандартом.

Да, я понимаю Ваше сомнение, в том смысле, что SADT не дает явных инструментов например реализации системы. Да в этом смысле SADT не поддерживает все этапы ЖЦ, как впрочем и ARIS. Тут, скажем, так я погорячился.

710

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

« : 06 Июня 2014, 14:21:38 »

Леонид, я привел часть известных мне определений. Раскрывать суть системного анализа не хочется, поскольку она разная с учетом точки зрения. Хотя в общем смысле СА предполагает ряд принципов, которые основаны на системном подходе.

Вообще эта тема довольно широко обсуждалась лет 5 назад. Я соглашусь с Натальей Желновой, что все перечисленные топикстартером методологии не являются методологиями только СА, но являются методологиями системной деятельности, т.е. покрывают весь (ну или часть) ЖЦ.

Если взять за основу то, что преподается в университетах (беру не наши, а зарубежные университеты), то СА

SYSTEMS ANALYSIS The purpose of the systems analysis phase is to build a logical model of the new system. The first step is requirements modeling, where you investigate
business processes and document what the new system must do to satisfy users. Requirements modeling continues the investigation that began during the systems planning phase. To understand the system, you perform fact-finding using techniques such as interviews, surveys, document review, observation, and sampling. You use the factfinding results to build business models, data and process models, and object models.     
The deliverable for the systems analysis phase is the system requirements document. The system requirements document describes management and user requirements, costs and benefits, and outlines alternative development strategies.

Т.е. СА может рассматриваться как научная дисциплина, или как фаза процесса системного строительства. Как фаза - это по сути работа с требованиями.

711

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

« : 06 Июня 2014, 09:38:05 »

Уважаемый/ая, igusew. Воздержитесь, пожалуйста, от той формы общения, которую Вы тут избрали. Обсуждайте свой вопрос конструктивно и общайтесь с оппонентами уважительно. Спасибо за понимание.

712

Теория моделирования и нотации / Re: Методологии системного анализа

« : 06 Июня 2014, 00:11:16 »

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

У меня есть подозрение, что Наталья тоже этого не знает. Поскольку у этого термина есть две области действия. Системный анализ (в филосовско-научно, категориально-абстрактном смысле) есть методология решения слабоструктурированных задач. Строго структурированные задачи решаются математическими методами. Неструктурированные - эвристическими методами. Задача СА уменьшить неопределенность исходной задачи. СА инструмент решения проблем (понимание проблемы).

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

вот тут еще чуть-чуть есть http://ru.wikipedia.org/wiki/Методика_системного_анализа

713

Вакансии / Re: Ищу колегу — преподавателя онлайн-курсов по системному анализу и требованиям

« : 30 Мая 2014, 23:36:08 »

Я по выходным на даче, а то бы предложил свою кандидатуру. Правда, не уверен с мелодичностью и некоторые пробелы в методике Коберна.

714

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

« : 21 Мая 2014, 23:35:05 »

Для того чтобы ощутить различия я обычно рассматриваю следующие свойства NEED и FEATURE:

- Иногда NEED не может быть удовлетворена за счёт автоматизации (или это дорого) и требуются другие решения (вне АС).

Да потребность - это не требование к системе, она может и не найти решения в системе

715

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

« : 21 Мая 2014, 23:34:07 »

Леонид, спасибо за анализ. Твердая 5-ка.

Однако авторы формулировок считали, что первая формулировка это потребность  (need) - у нее есть конечно заинтересованное лицо: работник абонемента и работник книжного фонда ( через проблему Отсутствие оперативного обновления информации о наличии)

Вторая формулировка - это требование возможности (feature)

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

716

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

« : 20 Мая 2014, 22:38:10 »

Эдуард, а можно пример-другой из числа частых разногласий?

Ну, сложно это сделать. Но попробую.

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

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

Ясно ли где тут что?

717

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

« : 20 Мая 2014, 18:37:10 »

А если автор темы объяснит, какую проблему он пытается решить методом данного обсуждения, я почти наверняка смогу помочь более существенным мнением.

Формулировки потребностей и возможностей (need и feature) довольно близки. При изучении этой темы (на практике), часто возникают разногласия . Хотя и поясняется, что потребность - это пожелание, которое может остаться мечтанием или превратится в требование, фича - уже требование, то чему должна соответствовать система (иметь свойства). Возможно я дую на воду, но предполагал, что есть какие-то маркеры позволяющие
а/ различать потребности и фичи
б/ корректно их формулировать чтобы не путать в последствие, ну хотя бы в рамках одной группы

718

Задачи студентов / Re: Диаграмма прецедентов простого антивируса

« : 19 Мая 2014, 20:42:01 »

Мне так нравится. Дитё задало вопрос и исчезло. Деды тешатся UML анализом.

719

Задачи студентов / Re: Диаграмма прецедентов простого антивируса

« : 19 Мая 2014, 08:34:08 »

Мне думается, ошибка в использовании include. Семантика этого отношения предполагает ОБЯЗАТЕЛЬНОЕ включение в базовый ВИ "Изменить настройки" всех включаемых ВИ. Получается, что каждый раз, когда пользователь предпринимает попытку изменения настройки, он меняет файл журнала, настройки интерфейса, меняет директорий сканирования, меняет реакцию на обнаруживаемые зараженные файлы. Так ли это? Не должно ли тут быть или отношения расширения, или обобщения?

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

720

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

« : 17 Мая 2014, 23:35:43 »

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

На самом деле это модель, выведенная из консультаций с Борисом Леонидовичем Новиковым - экспертом и, возможно, евангелистом RUP.
Заинтересованное лицо - лицо, имеющее определенный интерес в существовании системы.
Интерес - хотя и есть в модели, реально мною не используется. Concern - многозначное понятие. Чем оно отличается от проблемы, мне сказать, честно сложно.
Проблема - совпадает с Вашим пониманием.
Потребность (need) - высказанное или невысказанное пожелание то, что решает (по мнению ЗЛ) его проблемы.
Требование возможности (feature) - хотя Леонида передергивает, но RUP почему-то считает это требованиями. В практике RUP, в частности в ReqPro есть такой тип требования.
Требование прецедента - это не сам прецедент, но функциональное требование. Требование  - это условие, а прецедент - это договоренность об взаимодействии
Дополнительные требования - все что FURPS+
Функциональная область - уже часть решения - часть логической структуры или архитектуры