106
Для всех / Ресурс http://www.uml-rus.ru/
« : 07 Ноября 2009, 15:13:30 »
Случайно натолкнулся, посмотрите, стоит ли человека вовлечь в нашу сферу влияния?
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
107
Системный Анализ и Требования / Как мы играли в Управление требованиями по Agile
« : 31 Октября 2009, 23:02:22 »
Надеюсь, я не раскрою каких-то секретов.
В рамках конференции CEE-SECR 2009 я и мои коллеги по работе участвовали в игре-симуляции "Управление требованиями по Agile", проводимой Асхатом Уразбаевым и Никитой Филипповым.
Игра проходила так.
Было несколько столов по 6 человек. Каждой команде были выданы:
1. видение в некоторой формальной форме
2. шаблоны для описания персонифицированных ролей
3. стикеры
4. карточки с обязательными работами
5. кубик (кости)
Асхат или Никита делали некоторое объяснение по каждому этапу. Затем включался счетчик и команда должна за короткий период выполнить некоторую задачу.
1 этап заключался в выделении бизнес-драйверов. Так я узнал совершенно новый термин. Оказывается всякие бизнес-цйели, требования или потребности принято называть емким словом бизнес-драйвер. Итак наша задача заключалась в поисках 3 таких бизнес-драйверов.
Видение включало описание проблемы, связанной с деградацией общества и ухода из лона церкви. Решением такой проблемы должно было послужить создание ресурса Вцеркви.ру. Было выделено определенное количество денег и 3 месяца для того, чтобы понять эффективность таких мер. Было сказано также, что над подобной проблемой работают конкуренты.
Как потом оказалось наш бизнес-драйвер оказался ошибочным. Мы определили его так Сделать решение, чтобы получить полный бюджет. Можете ли вы сказать, а что должно было послужить определяющим бизнес-драйвером в этом случае?
2 этап заключался в выдлении о описании персонифицированных ролей. Нужно было выделить 4 роли и дать им описание:
Имя, описание роли, ценности роли. Т.е. нужно было представить определенного человека и дать его описание. Например:
Верующий Сергей. 30 лет, работник завода химических удобрений, женат, имеет двоих детей, не курит, не пьет. Православен. Ценности: Семья, Признание, Общение с единомышленниками ...
3 этап заключался в описании пользовательских историй в формате: Как <пользователь>, я могу <действие>, для того, чтобы <цель>. (Подробнее смотри статью User Stories, часть 1) Нужно было написать не меньше 4 историй.
4 этап заключался в приоритезации и оценке трудоемкости реализации каждой истории. В настоящей практики трудоемкость оценивалась в 10 балльной шкале. А приоритезация относилась к тому, как история помогает достигнуть поставленную цель - бизнес-драйвер. В игре мы заменили это бросанием костяшки. Сколько очков выпадало - столько и записывали
5 этап - планирование релиза и итераций. Каждая итерация равнялась 18 поинтов и должна была занимать 3 недели. Общее количество требований и расставленных баллов + 4 работы, связанных с развертыванием сервера БД и хоста для проекта и для тестирования давало, что наш релиз мог появится не раньше 4 месяцев.
Итак мы составили первую итерацию, как поступила вводная, что первую итерацию вследствие разных причин урезаетсядо 9 поинтов. Потребовалось перепланировать итерации. Посколько срок релиза жестко лимитрован, то нужно было принять решение - какую функциональность можно временно убрать из первого релиза.
Agile методика по словам Асхата в этом случае предполагает возможность пересмотра всего пула историй и даже видения, если обнаружены неточности, несоотвествия, или доверие к информации, изложенной в видении, сильно подорвано
На этом игра закончилась, так формат времени не позволял ее продолжать. К сожалению разбора полетов практически не было. Но нас пригласили принять участие в тренинге с 20% скидкой
В рамках конференции CEE-SECR 2009 я и мои коллеги по работе участвовали в игре-симуляции "Управление требованиями по Agile", проводимой Асхатом Уразбаевым и Никитой Филипповым.
Игра проходила так.
Было несколько столов по 6 человек. Каждой команде были выданы:
1. видение в некоторой формальной форме
2. шаблоны для описания персонифицированных ролей
3. стикеры
4. карточки с обязательными работами
5. кубик (кости)
Асхат или Никита делали некоторое объяснение по каждому этапу. Затем включался счетчик и команда должна за короткий период выполнить некоторую задачу.
1 этап заключался в выделении бизнес-драйверов. Так я узнал совершенно новый термин. Оказывается всякие бизнес-цйели, требования или потребности принято называть емким словом бизнес-драйвер. Итак наша задача заключалась в поисках 3 таких бизнес-драйверов.
Видение включало описание проблемы, связанной с деградацией общества и ухода из лона церкви. Решением такой проблемы должно было послужить создание ресурса Вцеркви.ру. Было выделено определенное количество денег и 3 месяца для того, чтобы понять эффективность таких мер. Было сказано также, что над подобной проблемой работают конкуренты.
Как потом оказалось наш бизнес-драйвер оказался ошибочным. Мы определили его так Сделать решение, чтобы получить полный бюджет. Можете ли вы сказать, а что должно было послужить определяющим бизнес-драйвером в этом случае?
2 этап заключался в выдлении о описании персонифицированных ролей. Нужно было выделить 4 роли и дать им описание:
Имя, описание роли, ценности роли. Т.е. нужно было представить определенного человека и дать его описание. Например:
Верующий Сергей. 30 лет, работник завода химических удобрений, женат, имеет двоих детей, не курит, не пьет. Православен. Ценности: Семья, Признание, Общение с единомышленниками ...
3 этап заключался в описании пользовательских историй в формате: Как <пользователь>, я могу <действие>, для того, чтобы <цель>. (Подробнее смотри статью User Stories, часть 1) Нужно было написать не меньше 4 историй.
4 этап заключался в приоритезации и оценке трудоемкости реализации каждой истории. В настоящей практики трудоемкость оценивалась в 10 балльной шкале. А приоритезация относилась к тому, как история помогает достигнуть поставленную цель - бизнес-драйвер. В игре мы заменили это бросанием костяшки. Сколько очков выпадало - столько и записывали
5 этап - планирование релиза и итераций. Каждая итерация равнялась 18 поинтов и должна была занимать 3 недели. Общее количество требований и расставленных баллов + 4 работы, связанных с развертыванием сервера БД и хоста для проекта и для тестирования давало, что наш релиз мог появится не раньше 4 месяцев.
Итак мы составили первую итерацию, как поступила вводная, что первую итерацию вследствие разных причин урезаетсядо 9 поинтов. Потребовалось перепланировать итерации. Посколько срок релиза жестко лимитрован, то нужно было принять решение - какую функциональность можно временно убрать из первого релиза.
Agile методика по словам Асхата в этом случае предполагает возможность пересмотра всего пула историй и даже видения, если обнаружены неточности, несоотвествия, или доверие к информации, изложенной в видении, сильно подорвано
На этом игра закончилась, так формат времени не позволял ее продолжать. К сожалению разбора полетов практически не было. Но нас пригласили принять участие в тренинге с 20% скидкой
108
Системный Анализ и Требования / Как и зачем документировать требования?
« : 29 Сентября 2009, 23:08:53 »
Разработка и в особенности документирование требований такая же важная и не менее сложная работа, как и другие дисциплины процесса разработки.
Вопрос документировать требования или нет - не стоит. Скорее есть вопрос в форме. По форме есть постоянные споры в нашей команде.
Одни утверждают описывать требования нужно, руководствуясь, здравым смыслом. Главное, чтобы смысл был понятен для тех кому этот документ предназначен. Так уж сложилось, что собственно ТЗ у нас не пишут, ну такое официальное ТЗ, которое следует подписывать с Заказчиком, утверждать его и неукоснительно исполнять. Скорее все моменты взаимоотношений прописываются в договоре, в котором собственно сторона разработчика берет на себя отвественость за устранение ошибок, добавления нужной новой функциональности, адаптация системы под нужды Заказчика, если это необходимо. Все это закрепляется подписями сторон и выплатой Заказчиком ежемесячных выплат установленной суммы.
Поскольку нет особых требований по написанию ТЗ, то форма описания требований часто флюктурирует и ... за частую определяется отделом проектирования. Т.е. требования (это у нас называется постановка) должны описываться так, чтобы их сумел понять проектный отдел и сформировать решение. Проектные решения сейчас принято публиковать на wiki. После реализации проектного решения результаты документируются в виде технологических инструкций - читай руководства пользователя позадачно.
Есть преимущества такого подхода:
- документирование требований в таком виде не требует больших затрат;
- до программиста доходит уже проектное решение достаточно сухое и более менее точное;
- отдается предпочтение "теплому" общению над "холодным"
Вместе с тем есть и недостатки:
- требования недостаточно формализованы, есть возможность их разного толкования
- проектные решения зачастую слишком сухи для например тестеров, которые вынуждены дожидаться практической реализации, прежде чем вообще смогут приступить с серьезному тестированию
- невозможно отследить изменения в требованиях или постановках (поскольку стиль документирования на wiki все-таки требует сознательного и активного контроля, а внимание часто отвлекается, и последующей мотивации привести документв соответствии с возникшими изменениями обычно не хватает)
- отсутствие стандарта
- критерий здравого смысла основывается на здравом смысле отдела проектирования?
Очевидно, что все еще осложняется отсутствием нормального процесса управления изменениями, управления требованиями.
Конечно, многое сглаживается, нивелируется активным взаимным общением. Задача решается и достаточно успешно. Насколько эффективно и производительно, мне трудно сказать.
Я вижу ситуацию со стороны тестирования. Я вижу, что к требованиям и постановкам стали относиться серьезнее, но все равно чего-то явно не хватает.
Что могут сказать гуру по требованиям и управлениями ими в этой связи?
Вопрос документировать требования или нет - не стоит. Скорее есть вопрос в форме. По форме есть постоянные споры в нашей команде.
Одни утверждают описывать требования нужно, руководствуясь, здравым смыслом. Главное, чтобы смысл был понятен для тех кому этот документ предназначен. Так уж сложилось, что собственно ТЗ у нас не пишут, ну такое официальное ТЗ, которое следует подписывать с Заказчиком, утверждать его и неукоснительно исполнять. Скорее все моменты взаимоотношений прописываются в договоре, в котором собственно сторона разработчика берет на себя отвественость за устранение ошибок, добавления нужной новой функциональности, адаптация системы под нужды Заказчика, если это необходимо. Все это закрепляется подписями сторон и выплатой Заказчиком ежемесячных выплат установленной суммы.
Поскольку нет особых требований по написанию ТЗ, то форма описания требований часто флюктурирует и ... за частую определяется отделом проектирования. Т.е. требования (это у нас называется постановка) должны описываться так, чтобы их сумел понять проектный отдел и сформировать решение. Проектные решения сейчас принято публиковать на wiki. После реализации проектного решения результаты документируются в виде технологических инструкций - читай руководства пользователя позадачно.
Есть преимущества такого подхода:
- документирование требований в таком виде не требует больших затрат;
- до программиста доходит уже проектное решение достаточно сухое и более менее точное;
- отдается предпочтение "теплому" общению над "холодным"
Вместе с тем есть и недостатки:
- требования недостаточно формализованы, есть возможность их разного толкования
- проектные решения зачастую слишком сухи для например тестеров, которые вынуждены дожидаться практической реализации, прежде чем вообще смогут приступить с серьезному тестированию
- невозможно отследить изменения в требованиях или постановках (поскольку стиль документирования на wiki все-таки требует сознательного и активного контроля, а внимание часто отвлекается, и последующей мотивации привести документв соответствии с возникшими изменениями обычно не хватает)
- отсутствие стандарта
- критерий здравого смысла основывается на здравом смысле отдела проектирования?
Очевидно, что все еще осложняется отсутствием нормального процесса управления изменениями, управления требованиями.
Конечно, многое сглаживается, нивелируется активным взаимным общением. Задача решается и достаточно успешно. Насколько эффективно и производительно, мне трудно сказать.
Я вижу ситуацию со стороны тестирования. Я вижу, что к требованиям и постановкам стали относиться серьезнее, но все равно чего-то явно не хватает.
Что могут сказать гуру по требованиям и управлениями ими в этой связи?
109
О Сайте и Форуме / Об эффективности работы сайта
« : 25 Сентября 2009, 09:42:24 »
Обнаружил такую статью:Диаграмма Спивака: новый метод анализа эффективности страниц сайта
Стоит ли протестировать сайт?
Стоит ли протестировать сайт?
110
Обучение / Обучение процессу разработки
« : 11 Сентября 2009, 12:20:12 »
Не мог определиться с названием темы, если кто-то предложит более точную - буду благодарен и исправлю в последствии.
Итак, в рамках академического курса в ходе практических занятий я бы хотел дать возможность студентам получить какие-то (желательно правильные ) навыки и знания, работая над неким учебным проектом.
В качестве темы я избрал пример Вигерса про систему заказов в кафетерии.
Примерные задачи в ходе такого проекта:
1. Выявление и анализ требований
2. Формирование видения
3. Специфицирование вариантов использования
4. Реализция вариантов использования
5. Разработка скажем прототипа системы
6. Тестирование системы
7. Подведение итогов - оценка результатов
Сегодня провел первый семинар, материалы в виде презентации прикладываются
Прошу высказать замечания по нему, возможно предложить, как лучше подать материал и организовать текущую и последующую работу.
В идеале хотелось бы организовать все так, чтобы группа студентов (21) работала с одним проектом как единым целым. В прошлом году пытался, не получилось.
Удалось разбиться по подгруппам, каждая их которых выполняла проект в целом, но с упором на свою зону ответственности. В итоге было сделано 5 проектов (разный дизайн, разная реализация). Вместе смотрели оценивали - было прикольно.
Итак, в рамках академического курса в ходе практических занятий я бы хотел дать возможность студентам получить какие-то (желательно правильные
) навыки и знания, работая над неким учебным проектом.В качестве темы я избрал пример Вигерса про систему заказов в кафетерии.
Примерные задачи в ходе такого проекта:
1. Выявление и анализ требований
2. Формирование видения
3. Специфицирование вариантов использования
4. Реализция вариантов использования
5. Разработка скажем прототипа системы
6. Тестирование системы
7. Подведение итогов - оценка результатов
Сегодня провел первый семинар, материалы в виде презентации прикладываются
Прошу высказать замечания по нему, возможно предложить, как лучше подать материал и организовать текущую и последующую работу.
В идеале хотелось бы организовать все так, чтобы группа студентов (21) работала с одним проектом как единым целым. В прошлом году пытался, не получилось.
Удалось разбиться по подгруппам, каждая их которых выполняла проект в целом, но с упором на свою зону ответственности. В итоге было сделано 5 проектов (разный дизайн, разная реализация). Вместе смотрели оценивали - было прикольно.
111
Термины и Определения / [Термин] Архитектура. ИС, ПС, ИТ, предприятия и т.п.
« : 08 Сентября 2009, 12:51:52 »
Готовлю курс Архитектура современных информационных систем.
Как всегда есть проблема и путаница с определениями.
1. Архитектура - От греч. Architektonike - строительное искусство. С этим все понятно
2. Архитектура - это организационная структура системы (IEEE Std. 610.12-1990)
Немного подискутируем.
Организационная структура (англ. organizational structure) - совокупность способов, посредством которых процесс труда сначала разделяется на отдельные рабочие задачи, а затем достигается координация действий по решению задач (Генри Минцберг, "Структура в кулаке"). По сути дела, организационная структура определяет распределение ответственности и полномочий внутри организации. Как правило, она отображается в виде органограммы - графической схемы, элементами которой являются иерархически упорядоченные организационные единицы (подразделения, должностные позиции).
ОРГАНИЗАЦИОННАЯ СТРУКТУРА (ОРГСТРУКТУРА) [organizational structure] — структура объекта управления (по другим определениям — структура экономической системы, организации как таковой), в которой элементами являются подразделения или отдельные участники системы, а связи выражают включенность участников или подразделений в другие подразделения.
Организация представляет собой общественный механизм, создание которого преследует коллективные цели, деятельность которого каким-то образом управляется, и который каким-то образом отделён от окружения.
Организация это целевое объединение ресурсов
или
ОРГАНИЗАЦИЯ [organization] — 1. О. системы — совокупность структуры системы и способов функционирования ее элементов. (Определение это не единственное: в ряде работ термины “О.” и “структура” в этом смысле отождествляются.)
В своём основном значении, структура есть внутреннее устройство чего-либо
СТРУКТУРА СИСТЕМЫ [system structure] — организация связей и отношений между подсистемами и элементами системы, а также собственно состав этих подсистем и элементов, каждому из которых обычно соответствует определенная функция.
3. Архитектура - фундаментальная организационная структура системы, воплощенная в ее компонентах, их взаимоотношениях между собой и с окружением, и принципы, управляющие ее построением и эволюцией (ANSI/IEEE Std 1471-2000)
Итак: архитектура это
организационная структура системы
приниципы построения и эволюции системы
Что порадовало. Структура - это организация, организация - это совокупность структур, оганизационная структура - структура объекта управления.
Архитектура = структура объекта управления системы???
4. Системная архитектура - организация и структура основных элементов информационной системы, имеющая принципиальное значение для функционирования системы в целом
архитектуру приложений — функциональный и компонентный состав информационной системы
архитектуру данных — способы взаимодействия систем и хранения данных
архитектуру оборудования — используемые технические средства/решения
5. Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы
6. Архитектура ИС - это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой и это набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения
С другой стороны см. Классификация информационных систем по архитектуре
Так что есть такое архитектура ИС? Какие они бывают?
Как всегда есть проблема и путаница с определениями.
1. Архитектура - От греч. Architektonike - строительное искусство. С этим все понятно
2. Архитектура - это организационная структура системы (IEEE Std. 610.12-1990)
Немного подискутируем.
Организационная структура (англ. organizational structure) - совокупность способов, посредством которых процесс труда сначала разделяется на отдельные рабочие задачи, а затем достигается координация действий по решению задач (Генри Минцберг, "Структура в кулаке"). По сути дела, организационная структура определяет распределение ответственности и полномочий внутри организации. Как правило, она отображается в виде органограммы - графической схемы, элементами которой являются иерархически упорядоченные организационные единицы (подразделения, должностные позиции).
ОРГАНИЗАЦИОННАЯ СТРУКТУРА (ОРГСТРУКТУРА) [organizational structure] — структура объекта управления (по другим определениям — структура экономической системы, организации как таковой), в которой элементами являются подразделения или отдельные участники системы, а связи выражают включенность участников или подразделений в другие подразделения.
Организация представляет собой общественный механизм, создание которого преследует коллективные цели, деятельность которого каким-то образом управляется, и который каким-то образом отделён от окружения.
Организация это целевое объединение ресурсов
или
ОРГАНИЗАЦИЯ [organization] — 1. О. системы — совокупность структуры системы и способов функционирования ее элементов. (Определение это не единственное: в ряде работ термины “О.” и “структура” в этом смысле отождествляются.)
В своём основном значении, структура есть внутреннее устройство чего-либо
СТРУКТУРА СИСТЕМЫ [system structure] — организация связей и отношений между подсистемами и элементами системы, а также собственно состав этих подсистем и элементов, каждому из которых обычно соответствует определенная функция.
3. Архитектура - фундаментальная организационная структура системы, воплощенная в ее компонентах, их взаимоотношениях между собой и с окружением, и принципы, управляющие ее построением и эволюцией (ANSI/IEEE Std 1471-2000)
Итак: архитектура это
организационная структура системы
приниципы построения и эволюции системы
Что порадовало. Структура - это организация, организация - это совокупность структур, оганизационная структура - структура объекта управления.
Архитектура = структура объекта управления системы???
4. Системная архитектура - организация и структура основных элементов информационной системы, имеющая принципиальное значение для функционирования системы в целом
архитектуру приложений — функциональный и компонентный состав информационной системы
архитектуру данных — способы взаимодействия систем и хранения данных
архитектуру оборудования — используемые технические средства/решения
5. Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы
6. Архитектура ИС - это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой и это набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения
С другой стороны см. Классификация информационных систем по архитектуре
Так что есть такое архитектура ИС? Какие они бывают?
112
Обучение / Дисциплина <Архитектура современных информационных систем>
« : 07 Сентября 2009, 11:03:02 »
В рамках магистратуры 230209 Информационные системы в научных исследованиях, есть дисциплина Архитектура современных информационных систем.
Тема для меня довольно новая. Предстоит большая работа по созданию этого курса. Хотелось бы сделать его кратким, понятным, полезным и в тоже время академичным.
Может ли кто-то дать совет как и какие темы рассматривать в рамках данной дисциплины.
Пока на примете у меня курс с intuit.ru Архитектура предприятия и книга Фаулера Архитектура корпоративных приложений
Тема для меня довольно новая. Предстоит большая работа по созданию этого курса. Хотелось бы сделать его кратким, понятным, полезным и в тоже время академичным.
Может ли кто-то дать совет как и какие темы рассматривать в рамках данной дисциплины.
Пока на примете у меня курс с intuit.ru Архитектура предприятия и книга Фаулера Архитектура корпоративных приложений
113
Книги, статьи и ресурсы / Ralph Stair, George Reynolds Fundamentals of Information Systems
« : 02 Сентября 2009, 13:29:59 »
Нет ли у кого такой книги? Сейчас есть уже 4 издание. Но думаю можно посмотреть и предыдущие. Желательно конечнов электронном виде
114
Обучение / Информационные системы в научных исседованиях
« : 31 Августа 2009, 21:00:39 »
Мы открыли магистратуру по этой специальности. Выбор именно этой специальности происходил "авторитарно" заведующим кафедрой. Логика выбора специальности в целом понятна, но...
Есть тут некоторая проблема. Проблема заключается в том, что большинство АСНИ или ИС для научных исследований, которые мне известны, ориентированы на физические, химические, производственные процессы.
А вот не подскажите ли примеры ИС в научных исследований для экономических вопросов?
Есть тут некоторая проблема. Проблема заключается в том, что большинство АСНИ или ИС для научных исследований, которые мне известны, ориентированы на физические, химические, производственные процессы.
А вот не подскажите ли примеры ИС в научных исследований для экономических вопросов?
115
Книги, статьи и ресурсы / Информационные системы и феноме жизни. В.В. Коштоев
« : 29 Августа 2009, 22:01:48 »
Еще в 2000 году я, ища материал для лекций по ТИПиС, обнаружил на просторах Интернета книгу В.В. Коштоева. Информационные системы и феномен жизни.
В то время я с интересом начал ее читать и обнаружил много интересного. Но в целом материал мне показался очень далеким от моего предмета поисков.
На днях, "перелистывая" свою электронную библиотеку, обнаружил эту книгу в ней. И начал ее читать повторно. Что интересно, обнаружил массу интересных моментов связанных с понятием "Информационная система".
Выкладываю эту книгу. Для начала предлагаю пробежаться по первой и второй главе.
В то время я с интересом начал ее читать и обнаружил много интересного. Но в целом материал мне показался очень далеким от моего предмета поисков.
На днях, "перелистывая" свою электронную библиотеку, обнаружил эту книгу в ней. И начал ее читать повторно. Что интересно, обнаружил массу интересных моментов связанных с понятием "Информационная система".
Выкладываю эту книгу. Для начала предлагаю пробежаться по первой и второй главе.
116
Термины и Определения / [Термин] Информационная система
« : 23 Августа 2009, 22:57:15 »
Как и полагается, термин - информационная система - столь же не однозначен, сколь под информационной системой понимаются совершенно разные понятия.
Мне хотелось бы открыть дискуссию по этому вопросу и попытаться хотя бы приблизиться к некоторому точному пониманию того,
что такое информационная система,
для чего предназначена информационная система,
каковы типовые функции информационной системы,
можно ли говорить об архитектуре информационной системы,
следует ли отличать проектирование информационной системы от проектированием скажем программной системы
Для начала определение из учебника по информатики Могилева и др.
Система - комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям (ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств. ГОССТАНДАРТ РОССИИ. Москва, 1999)
Автоматизированная система - …совокупность комплекса средств автоматизации, организационно-методических и технологических документов и специалистов, использующих их в процессе своей профессиональной деятельности (Из методических указаний РД 50-680-88 серии стандартов ГОСТ 34 на автоматизированные системы (АС))
Комплекс средств автоматизации автоматизированной системы - совокупность всех компонентов АС, за исключением людей (ГОСТ 34.003-90. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Термины и определения )
обратите внимания на два эти определения АС - это КСА +, а КСА - это АС - персонал а куда девались орг-метод и технолог документы? и что же такое это самое КСА?
а вот тут немного иное определение Автоматизированная система - комплекс технических, программных, других средств и персонала, предназначенный для автоматизации различных процессов.
Информационно-технологическая система (IT system) - набор информационно-технологических ресурсов, обеспечивающий услуги по одному или нескольким интерфейсам (ГОСТ Р ИСО/МЭК ТО 10000-1-99)
Информационная система - по законодательству РФ - организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы
Автоматизированная информационная система - комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства и информационные ресурсы, а также системный персонал и обеспечивающий поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей (Когаловский. Перспективные технологии информационных систем. Лекции МГУ)
Кроме того, можно предложить еще определение в англоязычном мире.
То, что определений много, это не так плохо. Эти определения не противоречат, как мы видим, друг другу. В англоязычных определениях вообще делается упор на ИС в общем смысле и ИС в узком смысле.
Мне хотелось бы открыть дискуссию по этому вопросу и попытаться хотя бы приблизиться к некоторому точному пониманию того,
что такое информационная система,
для чего предназначена информационная система,
каковы типовые функции информационной системы,
можно ли говорить об архитектуре информационной системы,
следует ли отличать проектирование информационной системы от проектированием скажем программной системы
Для начала определение из учебника по информатики Могилева и др.
Цитировать
Информационные системы - Раздел информатики, связанный с решением вопросов по анализу потоков информации в различных сложных системах, их оптимизации, структурирования, принципах хранения и поиска информации
Система - комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям (ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств. ГОССТАНДАРТ РОССИИ. Москва, 1999)
Автоматизированная система - …совокупность комплекса средств автоматизации, организационно-методических и технологических документов и специалистов, использующих их в процессе своей профессиональной деятельности (Из методических указаний РД 50-680-88 серии стандартов ГОСТ 34 на автоматизированные системы (АС))
Комплекс средств автоматизации автоматизированной системы - совокупность всех компонентов АС, за исключением людей (ГОСТ 34.003-90. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Термины и определения )
обратите внимания на два эти определения АС - это КСА +, а КСА - это АС - персонал
а куда девались орг-метод и технолог документы? и что же такое это самое КСА?а вот тут немного иное определение Автоматизированная система - комплекс технических, программных, других средств и персонала, предназначенный для автоматизации различных процессов.
Цитировать
Информационная система- система, предназначенная для сбора, передачи, обработки, хранения и выдачи информации потребителям и состоящая из следующих основных компонентов: программное обеспечение, информационное обеспечение, технические средства, обслуживающий персонал (Информационные системы в экономике: Учебник / Под ред. Проф. В.В. Дика. — М.: Финансы и статистика, 1996 )
Информационно-технологическая система (IT system) - набор информационно-технологических ресурсов, обеспечивающий услуги по одному или нескольким интерфейсам (ГОСТ Р ИСО/МЭК ТО 10000-1-99)
Информационная система - по законодательству РФ - организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы
Автоматизированная информационная система - комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства и информационные ресурсы, а также системный персонал и обеспечивающий поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей (Когаловский. Перспективные технологии информационных систем. Лекции МГУ)
Кроме того, можно предложить еще определение в англоязычном мире.
То, что определений много, это не так плохо. Эти определения не противоречат, как мы видим, друг другу. В англоязычных определениях вообще делается упор на ИС в общем смысле и ИС в узком смысле.
117
Книги, статьи и ресурсы / Унифицированный процесс разработки программного обеспечения
« : 20 Августа 2009, 20:07:12 »
Книга Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.
СПб.: Питер, 2002. - 496 стр. ISBN: 5-318-00358-3
Эту книгу я настоятельно рекомендую прочитать любому начинающему специалисту в области информационных технологий и в первую очередь специалистам в программном обеспечении и специалистам по информационным системам.
Книга выше всяких похвал. Думаю единственный ее недостаток, что это не учебник в прямом смысле, т.е. нет контрольных заданий, нет упражнений, нет хорошо разобраных примеров, иллюстрирующих теоретические построения.
Вместе с тем перевод книги в целом вполне корректный, хотя некоторые определения не совсем традиционны. Книга в целом скорее представляет хороший справочный материал по Унифицированному процессу, однако она изобилует ссылками на другие материалы, комментариями, поэтому и в учебном смысле она будет отличным дополнением или даже заменителем существующих в вузах курсов. Книга будет полезна и аналитикам, и архитекторам, и проектировщикам.
Материал подается очень доступно и доходчиво. Мысль излагается ясно и последовательно. Противоречия существуют, но не без этого.
Очень советую почитать часть, посвященную работе с вариантами использования. Возможно вы не найдете идеальных рекомендаций по написанию спецификаций ВИ, но зато поймете почему, где и как нужно использовать ВИ.
Книгу не трудно скачать. Она есть во многих местах. Если есть возможность приобрести книгу - сделайте это!
Единственное но... UML старой версии, это может создать некоторую незначительную путаницу в использовании диаграмм. Но, мне кажется, не настолько очевидную. Если бы я не сказал об этом, наверное, мало бы кто и заметил
СПб.: Питер, 2002. - 496 стр. ISBN: 5-318-00358-3
Эту книгу я настоятельно рекомендую прочитать любому начинающему специалисту в области информационных технологий и в первую очередь специалистам в программном обеспечении и специалистам по информационным системам.
Книга выше всяких похвал. Думаю единственный ее недостаток, что это не учебник в прямом смысле, т.е. нет контрольных заданий, нет упражнений, нет хорошо разобраных примеров, иллюстрирующих теоретические построения.
Вместе с тем перевод книги в целом вполне корректный, хотя некоторые определения не совсем традиционны. Книга в целом скорее представляет хороший справочный материал по Унифицированному процессу, однако она изобилует ссылками на другие материалы, комментариями, поэтому и в учебном смысле она будет отличным дополнением или даже заменителем существующих в вузах курсов. Книга будет полезна и аналитикам, и архитекторам, и проектировщикам.
Материал подается очень доступно и доходчиво. Мысль излагается ясно и последовательно. Противоречия существуют, но не без этого.
Очень советую почитать часть, посвященную работе с вариантами использования. Возможно вы не найдете идеальных рекомендаций по написанию спецификаций ВИ, но зато поймете почему, где и как нужно использовать ВИ.
Книгу не трудно скачать. Она есть во многих местах. Если есть возможность приобрести книгу - сделайте это!
Единственное но... UML старой версии, это может создать некоторую незначительную путаницу в использовании диаграмм. Но, мне кажется, не настолько очевидную. Если бы я не сказал об этом, наверное, мало бы кто и заметил
118
UML SysML и пр. / Абстрактный вариант использования
« : 22 Июля 2009, 23:01:23 »
Здесь и здесь началась и может быть ЗДЕСЬ будет продолжена дискуссия про абстрактные ВИ.
Нужно признать, что мои представления об абстрактности несколько иные, чем у изобретателей UML и, в частности, use cases.
Действительно, кто же как не Ивар должен значть все об абстракции ВИ. Он же их придумал, он же их развивал.
Правда есть другой центр влияния. Он известен нам под именем Алистера Коберна. В русском издании на слово абстрактный нет ни одного совпадения. В английском издании мне встретилось только четыре совпадения, ничего собственно не проясняющие по данному поводу. Правда в русском переводе часто встречается термин обобщение. Что соответствует термину summary level, но никак не abstract.
Насчет понятия абстракция почитайте здесь. И начнем дискуссию
Я пока начинаю собирать коллекцию определений:
1. Essential (Abstract) Use Cases
An essential use case (Constantine and Lockwood 1999), sometimes called a business use case, is a simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner. A fully documented essential use case is a structured narrative, expressed in the language of the application domain and of users, comprising a simplified, abstract, technology-free and implementation-independent description of one task or interaction. An essential use case is complete, meaningful, and well designed from the point-of-view of users in some role or roles in relation to a system and that embodies the purpose or intentions underlying the interaction.
2. Abstract and Concrete Use Cases
concrete use case is a particular type of use case that is directly invoked by an actor and achieves a specific goal. It is self-contained and illustrates a complete flow of events. A concrete use case is a specific instance of using a common set of steps referred to as an abstract use case.
An abstract use case is a particular type of use case that is not directly invoked by an actor but is called by another use case.
3. Concrete and Abstract Use Cases
There is a distinction between concrete and abstract use cases. A concrete use case is initiated by an actor and constitutes a complete flow of events. "Complete" means that an instance of the use case performs the entire operation called for by the actor.
An abstract use case is never instantiated in itself. Abstract use cases are included in, extend into, or generalize other use cases. When a concrete use case is initiated, an instance of the use case is created. This instance also exhibits the behavior specified by its associated abstract use cases. Thus, no separate instances are created from abstract use cases.
The distinction between the two is important, because it is concrete use cases the actors will "see" and initiate in the system.
You indicate that a use case is abstract by writing its name in italics.
Впрочем это Виталий приводил. Собственно больше не нашел.
Нужно признать, что мои представления об абстрактности несколько иные, чем у изобретателей UML и, в частности, use cases.
Действительно, кто же как не Ивар должен значть все об абстракции ВИ. Он же их придумал, он же их развивал.
Правда есть другой центр влияния. Он известен нам под именем Алистера Коберна. В русском издании на слово абстрактный нет ни одного совпадения. В английском издании мне встретилось только четыре совпадения, ничего собственно не проясняющие по данному поводу. Правда в русском переводе часто встречается термин обобщение. Что соответствует термину summary level, но никак не abstract.
Насчет понятия абстракция почитайте здесь. И начнем дискуссию
Я пока начинаю собирать коллекцию определений:
1. Essential (Abstract) Use Cases
An essential use case (Constantine and Lockwood 1999), sometimes called a business use case, is a simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner. A fully documented essential use case is a structured narrative, expressed in the language of the application domain and of users, comprising a simplified, abstract, technology-free and implementation-independent description of one task or interaction. An essential use case is complete, meaningful, and well designed from the point-of-view of users in some role or roles in relation to a system and that embodies the purpose or intentions underlying the interaction.
2. Abstract and Concrete Use Cases
concrete use case is a particular type of use case that is directly invoked by an actor and achieves a specific goal. It is self-contained and illustrates a complete flow of events. A concrete use case is a specific instance of using a common set of steps referred to as an abstract use case.
An abstract use case is a particular type of use case that is not directly invoked by an actor but is called by another use case.
3. Concrete and Abstract Use Cases
There is a distinction between concrete and abstract use cases. A concrete use case is initiated by an actor and constitutes a complete flow of events. "Complete" means that an instance of the use case performs the entire operation called for by the actor.
An abstract use case is never instantiated in itself. Abstract use cases are included in, extend into, or generalize other use cases. When a concrete use case is initiated, an instance of the use case is created. This instance also exhibits the behavior specified by its associated abstract use cases. Thus, no separate instances are created from abstract use cases.
The distinction between the two is important, because it is concrete use cases the actors will "see" and initiate in the system.
You indicate that a use case is abstract by writing its name in italics.
Впрочем это Виталий приводил. Собственно больше не нашел.
119
MDA / Выпадающий список в BoldGrid
« : 08 Июля 2009, 09:07:40 »
Предположим есть такая конструкция:
Занятие (1..n)[занятия] ------[дисциплины] (1) Дисциплина
Далее я делаю приложение. Тонкости объяснять думаю не надо, кто в теме тот знает, что манипуляции тут очень простые.
Итак: создаю boldhandle для Занятия listLessons например. Создаю BoldGrid. Связываю его с listLessons и создаю столбцы по умолчанию. Далее добавляю еще один столбец и именую его По дисциплине. Создаю еще один handle listCourses.
Для свойства LookupHandle поля По дисциплине задаю listCourses. Запускаю приложение - выпадающий список работает, только отображает не совсем то что хотелось, т.е. не название дисциплины.
Тогда настраиваю LookupPropeties для этого поля, а именно в Expresion подставляю НазваниеДисциплины
Запускаю приложение. Добавляю запись. В выпадающем списке есть наименования дисциплин, однако если выбрать одну в поле так ничего и не отображается. Если открыть автоформу и задать дисциплину там - дисциплина будет отображаться, но переназначить, ее нельзя
Каков порядок работы - ситуация типичная...
Занятие (1..n)[занятия] ------[дисциплины] (1) Дисциплина
Далее я делаю приложение. Тонкости объяснять думаю не надо, кто в теме тот знает, что манипуляции тут очень простые.
Итак: создаю boldhandle для Занятия listLessons например. Создаю BoldGrid. Связываю его с listLessons и создаю столбцы по умолчанию. Далее добавляю еще один столбец и именую его По дисциплине. Создаю еще один handle listCourses.
Для свойства LookupHandle поля По дисциплине задаю listCourses. Запускаю приложение - выпадающий список работает, только отображает не совсем то что хотелось, т.е. не название дисциплины.
Тогда настраиваю LookupPropeties для этого поля, а именно в Expresion подставляю НазваниеДисциплины
Запускаю приложение. Добавляю запись. В выпадающем списке есть наименования дисциплин, однако если выбрать одну в поле так ничего и не отображается. Если открыть автоформу и задать дисциплину там - дисциплина будет отображаться, но переназначить, ее нельзя
Каков порядок работы - ситуация типичная...
120
Проектирование / Проектирование классов
« : 30 Июня 2009, 20:48:13 »
Есть у меня определенный пробел в знаниях, который хотелось бы закрыть. Даже не пробел в знаниях, а пробел в осознанном понимании.
Построить аналитическую модель классов не составляет труда. Но при переходе к проектной модели, а дальше к реализации, причем последнее очень важно, возникает сказанное выше.
Читаешь книги, понимаешь, что написано, даже вроде реализуешь, но все не то.
Потому прошу помощи по этому вопросу.
Несколько исходных положений.
Есть некая аналитическая модель, задача преобразовать ее в достаточную для создания кода модель классов.
Пусть существует Клиент, который может делать множество заказов.
В каждом заказе можно заказать один или множество товаров
Один и тот же товар может быть заказ много раз в разных заказах
Каждому заказу присваивается некий уникальный номер.
В результате получается например модель1
Как учат знатоки, все ассоциации должны быть уточнены до агрегаций и композиций. Решены вопросы навигации, разрулены кратности связей. Вот как раз это и вызывает затруднения.
Если есть интерес - предлагайте варианты, возможно с кодом и объяснением.
Спасибо
Построить аналитическую модель классов не составляет труда. Но при переходе к проектной модели, а дальше к реализации, причем последнее очень важно, возникает сказанное выше.
Читаешь книги, понимаешь, что написано, даже вроде реализуешь, но все не то.
Потому прошу помощи по этому вопросу.
Несколько исходных положений.
Есть некая аналитическая модель, задача преобразовать ее в достаточную для создания кода модель классов.
Пусть существует Клиент, который может делать множество заказов.
В каждом заказе можно заказать один или множество товаров
Один и тот же товар может быть заказ много раз в разных заказах
Каждому заказу присваивается некий уникальный номер.
В результате получается например модель1
Как учат знатоки, все ассоциации должны быть уточнены до агрегаций и композиций. Решены вопросы навигации, разрулены кратности связей. Вот как раз это и вызывает затруднения.
Если есть интерес - предлагайте варианты, возможно с кодом и объяснением.
Спасибо