4966

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

« : 08 Сентября 2007, 22:28:40 »

Утверждения автора о том, что из структуры системы можно "вывести её функции" (и цели?) представляется как минимум чересчур категоричным...

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

Анфилатов и др. Системный анализ в управлении. М.: Финансы и статистика, 2002?

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

возможно это обыгрывалось Сурминым?

4967

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

« : 08 Сентября 2007, 22:22:17 »

Некоторые цитаты:

Антонов А.В. Системный анализ. М.: Высшая школа, 2004. Учебник для вузов предназначен для ИТ специальностей .

Рецензенты Черненький В.М. из МГТУ(Баумана) каф АСОУИ

"... Цели системы - желательные состояния или результаты поведения системы. Глобальная цель системы - конечное состояние, к которому стремится система в силу своей структурной организации. Цель можно также определить следующим образом: «цель - это субъективный образ (абстрактная модель) несуществующего, но желаемого состояния среды, которое решило бы возникшую проблему» [16]. В практических применениях цель - это идеальное устремление, которое позволяет коллективу увидеть перспективы или реальные возможности, обеспечивающие своевременное завершение очередного этапа на пути к идеальным устремлениям. Цель достигается путем решения задач. Задачи системы - цели, которые желательно достичь к определенному моменту времени в пределах определенного периода функционирования системы." (стр. 65-66)

"Решение задачи, сформулированной в предыдущем параграфе, а именно, изучение структуры системы, анализ ее компонентов, выявле' ние взаимосвязей между отдельными элементами, преследует цель отразить статическое состояние системы. Однако при проведении системного анализа исследователя интересуют вопросы, касающиеся изучения свойств системы. Свойства системы реализуются в процессе ее функционирования, т.е. в процессе динамического поведения системы. Чтобы построить модель системы, которая имела бы возможность отражать свойства и характеристики системы, реализующиеся в процессе ее функционирования во времени, необходимо помимо структуры системы знать ее параметры, поэтому следующим этапом работ при проведении системного анализа является сбор данных о функционировании системы и исследование информационных потоков." (стр. 68)

4968

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

« : 08 Сентября 2007, 21:21:18 »

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

Пытался вычислить место положение автора. Наткнулся на это http://www.education.rekom.ru/2_2007/4.html

Судя по званию и титулам, вряд ли он снизойдет до нашего общества.

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

4969

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

« : 07 Сентября 2007, 19:38:00 »

Готовлюсь к лекциям по теории информационных процессов и систем. В качестве  одного и из разделов выступает теория систем и ситемный анализ. Обнаружил интереснейшую книгу Ю.П. Сурмин. Теория систем и системный анализ. К.: МАУП, 2003.

В качестве примера цитата:

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

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

далее

модель системы— объект, который представителен системе, может замещать ее в исследовательском или практическом процессе, а полученные результаты могут переноситься на саму систему;

проект системы — модель системы как средство конструирования системы.

таким образом я делаю вывод, что проектирование системы - это построение модели системы с использованием конструктивного подхода

Можно ли понимать, что дескриптивный подход проявляется при бизнес-анализе и моделировании системы?

Скачать книгу можно здесь

4970

Сообщество Аналитиков / Re: Присоединение к Сообществу Аналитиков России

« : 07 Сентября 2007, 10:50:53 »

Я искренне рад, что Ира пополнила наши ряды. Давно этого ждал. Теперь в наших рядах есть  девушка, просьба холить и лелеять

А я ее давно лелелю, правда Ира?

4971

Обучение / Требование к содержанию квалификационной работы

« : 06 Сентября 2007, 12:17:37 »

Новый учебный год с новыми идеями.

Вернее не идеями, а предложениями. От одного преподавателя поступило предложение обновить и уточнить тербования к содержанию квалификационных работ по специальности Информационные системы и технологии.
Он же произвел достаточно серьзеную работы и подготовил проект методических указаний. В основу указания преподаватель положил ГОСТ серии 34.

Структура методуказаний примерно такова.

1   Область применения
2   Основные положения
3   Структура пояснительной записки дипломного проекта
4   Структура основной части пояснительной записки дипломного проекта
5   Техническое    задание
5.1   Перечень разделов технического задания
5.2    Назначение системы
5.3    Цели создания системы
5.4    Характеристика объектов автоматизации (и информатизации)
5.5    Требования к системе
5.6   Состав и содержание работ по созданию системы
5.7   Порядок контроля и приемки системы
5.8   Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
6   Технический проект
6.1   Перечень разделов технического проекта
6.2    Пояснительная записка к техническому проекту
6.3    Схема функциональной структуры
6.4   Описание автоматизируемых функций
6.5   Программа и методика испытаний
6.6   Схема организационной структуры
6.7   Описание организационной структуры
6.8   Описание информационного обеспечения системы
6.9   Описание организации внутримашинной информационной базы
6.10   Решения по программному обеспечению
6.11   Решения по математическому обеспечению
7   Рабочая документация
7.1   Состав рабочей документации
7.2   Руководство пользователя
7.3   Описание технологического процесса обработки данных
8   Ввод в действие
   Приложение А

При прочтении у меня создалось неодназначное впечатление.

С одной стороны указания следуют основным положениям ГОСТов.

-ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
-ГОСТ 34.601-90 Информационная технология. Автоматизированные системы. Стадии создания;
-ГОСТ 34.602-89 Информационная технология. Техническое задание на создание автоматизированной системы;
-ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем;
-РД 50-34.698-90 Информационная технология. Автоматизированные системы. Требования к содержанию документов;
- ГОСТ 19.701-90 (ИСО 5807-85) Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения

Но с другой стороны они слишком формализованы.

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

Интересно какие указания на подобную тему используются в других вузах?

Какие соображения у сообщества и посетителей форума по виду указаний и содержанию дипломных проектов?

Могли бы вы поделиться (прицепить) методические указания на дипломное проектирование, чтобы посмотреть и сравнить?

Общие мои замечание: используется ГОСТ для оформления алгоритмов и графической части совершенно не учитывающий факт наличие других нотаций и подходов, существование ОО парадигмы, UML, методологий разработки ПО и систем.

4972

UML SysML и пр. / Re: Подскажите, какой вид диаграммы UML выбрать?

« : 05 Сентября 2007, 20:16:50 »

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

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

Для передачи зрительного образа можно воспользоваться например Corel, хотя и в EA легко заменить стандартные изображения аттрактивными картинками. Используйте стереотипы. В Розе для отображения компонентов как раз и используются стереотипы: документ, файл, библиотека, скрипт и т.п.
Компоненты можно смешивать с процессами и узлами на диаграмме размещения

4973

Обучение / Re: Появилась в продаже книга Вигерса "Разработка требований к программному обеспечению"

« : 05 Сентября 2007, 20:12:13 »

Я могу заказать для тебя. Для себя уже заказал.

Я Лармана заказал

4974

UML SysML и пр. / Re: Подскажите, какой вид диаграммы UML выбрать?

« : 05 Сентября 2007, 20:11:39 »

Как думаете, есть смысл дорисовать и детализировать свою «нотацию» или всё же пытаться чего-то намутить с помощью UML? Вообще я, конечно, удивлён, что в UML абстрагирование ведёт к такой проблеме как потеря наглядности.

Может проблема не в UML, а в Ваших его знаниях?

4975

Обучение / Появилась в продаже книга Вигерса "Разработка требований к программному обеспечению"

« : 05 Сентября 2007, 17:56:05 »

Хитрым образом стоило мне только заказать английскую версию Вигерса, как русская появилась на books.ru! )

Ты думаешь, это как-то взаимосвязанно?
 
Интересно а какую бы книгу заказать?

4976

Сообщество Аналитиков / Re: Программа сообщества

« : 05 Сентября 2007, 17:53:24 »

Денис, ты молодец!

Конечно, то, что написано, нуждается в доработке и шлифовке. Но дело положено, надо его продолжать.

В программе - сделать анализа российского рынка ИТ-анализа. А такой имеется? И в чем он выражается?

Обучение - нужно расскрывать более точно.
Есть например задумка создания ряда практических примеров с использованием различных инструментов и возможно по различным методикам. Но это пассивное обучение. Какие у нас есть варианты с активным? Возможно мастер-классы по типу Happy-pm(Александра Орлова). Сначала бесплатные, а потом и платные. Это возможно?

Анализ и рекомендация литературы и периодики

Может регулярные ИТ-семинары с приглашением авторитетных людей ну и нас конечно (я имею в виду нас как авторитетных ?

4977

О Сайте и Форуме / Re: Внимание! Плановые работы на Сайте и Форуме.

« : 05 Сентября 2007, 17:32:17 »

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

Останемся? Или будем переезжать?

4978

Для всех / Re: Ищу себя, нужна помощь

« : 05 Сентября 2007, 11:35:54 »

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

ДжейКей, бюрократию никто не любит. Есть конечно такие педанты, но они наверное испорчены в раннем детстве.
Однако как тут все говорят без писанины не обойтись. Однако если Вы работает в команде, а Ваш менеджер проектов - отличный менеджер - он и сам постарается Вас оградить от того, чего Вы не любите или не умеете.
Другой выход - Вы как раз можете сделать систему, которая то, что вы не любите превратит в увлекательный процесс - как Вам такая идея?

4979

UML SysML и пр. / Re: Подскажите, какой вид диаграммы UML выбрать?

« : 04 Сентября 2007, 21:52:38 »

Добрый день,

Добрый вечер и вам!

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

Вы вероятно имеете в виду архитектуру. В этом случае Вам помогут диаграммы компонентов. Диаграмма развертывания - это уже физический образ системы. На рисунке у Вас больше похоже на диаграмму компонетов. Хотя есть и элементы диаграммы развертывания.

В общем, если я правильно понял и требуется представить именно структуру компонентов системы без привязки к физическому их расположению - то это диаграмма компонентов - однозначно!

4980

Примеры / Re: Описание требований к CRM

« : 04 Сентября 2007, 13:39:11 »

Привет всем архитекторвующим!
Вот не знаю как обозвать сущность фирма-предприятие. В наиболее известных CRM используется значение ACCOUNT для этого, но ACCOUNT - это и набор данных для регистрации пользователей в системе. Тем более я демаю CRM для рекламного бизнеса, а там это слово именно и обозначает клиента-организацию. Кто сталкивался с этим? Решил ролевую сущность обозначающую права доступа к системе и элементам интерфейса назвать ACCESS.

CUSTOMER
CLIENT
advertising account ["xdvqtaIzINq'kaVnt]
заказчик, клиент рекламного агентства, рекламодатель
PATRON -    1) (постоянный) покупатель, клиент; постоянный посетитель
CONSUMER
PROSPECT 3.   предполагаемый покупатель, клиент, подписчик, кандидат и т. п.
ACCOUNT 2) (любой) заказчик, покупатель, клиент