181

Системный Анализ и Требования / Обсуждение статьи: CMMI — шаг в будущее: разработка требований

« : 13 Ноября 2007, 18:27:44 »

Хотелось бы получить критику или разъяснение статьи CMMI — шаг в будущее: разработка требований

Цитата1.
Требования клиента могут быть выражены в его собственных терминах и представлять собой нетехнические описания. Требования к продукту являются представлением требований клиента с помощью технической терминологии и могут быть использованы для проектных решений.

Вопрос 1.
Что значит выражены "с помощью технической терминологии"?

Цитата 2.
Разработка концепций и сценариев использования системы является первым шагом процесса анализа и утверждения требований

Вопрос 2.
Правильно ли я понимаю, что разработка концепции и ВИ есть суть анализа и осуществляется после сбора " требований клиента, требований к продукту и его компонентам, требований к компонентам продукта, требований к интерфейсам". Просто я как-то наивно полагал, что концепция делается до начала массового сбора требований?

Цитата 3 
Сценарий представляет собой последовательность событий, которые могут произойти при использовании продукта. Сценарий обычно используется, чтобы «высветить» некоторые потребности заинтересованных сторон. В отличие от сценария, концепция работы описывает, каким образом продукт используется или работает. Концепция зависит как от проектных решений, так и от сценария. Обычно при начальной выработке концепции альтернативные решения еще не существуют, поэтому концептуальные решения разрабатываются для анализа требований. По мере разработки технических решений и соответствующей разработки детальных требований нижнего уровня концепция работы может уточняться. Точно так же, как проектное решение для продукта может стать требованием для компонента продукта, концепция работы может стать сценарием (требованием) для компонентов продукта.

Вопрос 3
Как совершенно не въезжаю в то, что тут написано. То, что не понятно, подчеркнул.

182

Нововведения / Процесс обратной семантической трассировки

« : 05 Ноября 2007, 20:52:35 »

Хочу привлечь к теме, которую Саша(BAS) уже анонсировал при отчете о конфернеции SEC(R).

И так результатом 6 летних усилий стало появление на свет так называемого каркаса P-моделирование (INTSPEI P-Modeling Framework). Скачать каркас можно с сайта института.

В основе лежит так называемое безмолвное моделирование (speechless modeling) и процесс обратной семантической трассировки

Вот что написано:
" Безмолвное Моделирование - мощный метод моделирования, который помогает увеличивать производительность проектировщиков и улучшать качество дизайна.

Сущность Безмолвного Моделирования - ограничение на использование в ходе взаимодействия непосредственного или косвенного применения естественного языка. Через этот метод, группа проектировщиков вынуждена использовать язык моделирования как единственный язык, доступный для связи в течение сеанса дизайна. Любая устная или письменная связь, вовлекающая естественные языки запрещается.

Группы, разрабатывая UML модели без использования правильных (regular) языков фактически превзошли по быстродействию "нормальные" группы, кто действительно использовал естественный язык. Критические причины для такого увеличения в работе лежат в следующем:

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

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

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


"Сеанс P-моделирования - комбинация Безмолвного Моделирования и Обратной Семантической Трассируемости в один случай. Безмолвный Сеанс - мощный метод моделирования, который позволяет группе выпускать истинный творческий потенциал архитекторов и разработчиков. Главная цель Безмолвного Сеанса состоит в том, чтобы создать дизайн высокого качества и иметь общее понимание архитектуры будущего проекта. В течение этого сеанса, использование любого естественного языка не разрешается; только графический язык моделирования (типа UML) позволяется. Рекомендуется, чтобы группа имела приблизительно 3 часа для тихого моделирования. После Безмолвного Сеанса, Обратная Семантическая Трассируемость выполняется, чтобы проверить правильность созданной архитектуры."

Никто не желает попробывать?

183

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

« : 04 Ноября 2007, 14:43:00 »

Хотел бы задать вопрос общественности форума, особенно той ее части, которая реально работает с требованиями на практике и имеет насущную потребность в управлении ими.

Что хотелось бы узнать:

Каким образом Вы управляете требованиями?

Что Вы понимаете под управлением требованиями?

Какие системы управления требованиями Вы пользуетесь и как?

Как обеспечивается управление требованиями в стиле прецедентов и стиле списков свойств системы?

Какой подход в формулировке требований Вы обычно используете: водопадный или итерационный?

Какое место занимает в Вашем случае моделирование?

Используете ли Вы для проверки и анализа требований имитационное или математическое моделирование?

Какие требования к системе управления требованиями Вы лично предъявляете?

Вот некоторые ссылки для затравки:
Обсуждение на форуме sql.ru
Статья "Управление требованиями и автоматизация этого процесса"
Новые приемы управления требованиями с помощью Rational RequisitePro: Часть 1. Использование архитектурных методов

184

Обучение / Дипломный проект как IT проект

« : 31 Октября 2007, 19:59:18 »

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

Сроки дипломной работы очень ограничены - максимум 4-5 месяцев.

Идеально, конечно, это летняя практика после 4 курса, курсовой проект в 1 семестре и дипломный проект во втором.

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

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

Это присказка, не сказка, сказка будет впереди.

Мы уже тут дискутировали по поводу содержательно части дипломных проетов. Очевидно как минимум он может содержать техническое задание, проектное решение, описание программы.

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

Что содержится в ТЗ - более или менее понятно. Чаще всего это текст требований иногда какие-то контекстные модели. Я видел не так много ТЗ по ГОСТ, но в них не видел структурных схем, либо они были очень иллюстративные.

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

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

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

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

185

О Сайте и Форуме / Топ популярности файлов файлового архива. Ноябрь 2007.

« : 25 Октября 2007, 22:46:58 »

Object-Oriented Analysis and Design : Understanding System Development with UML 2.0	17567
Бизнес моделирование по RUP	8344
Применение UML и шаблонов проектирования	6323
Введение в Rational Unified Process	5852
Rational Unified Process	2521

186

О Сайте и Форуме / Недоступность сайта и форума

« : 24 Октября 2007, 22:57:35 »

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

187

Системный Анализ и Требования / Сбор требования или информации для неизвестного пока решения

« : 09 Октября 2007, 19:16:16 »

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

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

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

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

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

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

Как целесообразно и грамотно действовать в этой ситуации? У кого какие предложения и рекомендации, личные мылси или возможно личный опыт?

188

Обучение / Совместная разработка лекционных курсов

« : 07 Октября 2007, 22:13:08 »

Уважаемый преподаватель, сталкивались ли Вы с проблемой написания курса лекций, постановки семинарских и лабораторных занятий? Приходилось ли Вам начинать некую незнакомую тему? Или выбирать из большого огромного потока разной информации нечто, что Вы в конце захотите внедрить в свой курс лекций? А потом вдруг понимать, что Вы совершенно не так все понимали? А кто расплачивается за наши метания и поиски - студент!

Можно защитить его интересы и удовлетворить собственные, повысить уровень знаний и найти благодарную аудиторию для взаимопонимания и сотрудничества

Посетила меня такая идея. Идея вполне на поверхности, но как иногда бывает, простая идея требует сложной реализации. Идея такая - писать лекции вместе.

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

Процесс совместной работы в настоящее время реализовать просто. Могу у себя создать необходимые ресурсы, можно воспользоваться услугами других людей.

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

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

Что интересует меня в первую очередь:

Теория информационных процессов и систем - вообще хотелось бы понять, что эта такое теория ИП и ИС, много чего понаписать можно

Моделирование систем (визуальное моделирование)

Корпоративные информационные системы

Проектирование информационных систем

и другие.

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

Затем сформировать он-лайн ресурс (wiki-технология) с авторизованным доступ.

Представители бизнеса будут неким контролирующим, критикующим органом (если захотят).

189

Обучение / Спецификация требований к системе

« : 29 Сентября 2007, 22:45:49 »

Не уверен, куда отнести лучше эту тему. Потому поместил пока в данном разделе. Думаю потом можно перенести.

Внимательно изучая спеццификацию требований к программному обеспечению, перевод которой был выложен в одной из тем на форуме, обнаружил фразу, которая ссылается на спецификацию требований к системе (перевод SRS STD стандарта IEEE 830).
Насколько  я понимаю ссылка идет на Стандарт IEЕЕ 1233, Издание 1998 года, Руководство IEЕЕ по разработкам спецификаций системных требований. Интересно бы узнать его содержание (желательно в переводе) у кого-то есть?

190

Обучение / Требуются задачи на моделирование конечных автоматов или диаграмм состояний

« : 26 Сентября 2007, 17:12:52 »

В течение ряда лет я преподаю дисциплину по кодовым названием Моделирование систем.

В рамках оной мы изучаем различные математические модели в соответствии с учебником Советова с такми же названием. Моделирование моделей производится в хорошо известной среде MatLab. В первую очередь  мы используем среду визуального моделирования Simulink.

Среди развитых инструментов Simulink имеется расширение StateFlow, представляющее собой графическую среду моделирования конечных автоматов, основанную на карта Харела - прямой аналог диаграмм состояний в UML. Думаю, диаграммы состояний были реализованы на основе карт Харела.

У меня есть несколько задач на использование концепции StateFlow для изучения детерминированного и вероятностного конечных автоматов.

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

Диаграммы состояний в UML применяются для описания поведения объекта или системы в целом. Таким образом, можно связать формирование диаграмм состояний с их имитационным моделированием в StateFlow.

Но что-то не придумывается как это сделать.

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

Есть какие-то идеи? Задачки ? Прошу публиковать здесь. Их реализацию будут пытаться сделать и публиковать результаты.

191

Обучение / Опыт преподавания структурного анализа

« : 20 Сентября 2007, 10:19:16 »

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

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

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

Техника проведения эксперимента примерна такая же как для эксперимента преподавания объектно-ориентированного анализа:

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

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

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

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

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

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

Впредь планирую никак не сдерживать инициативу и творчество студентов.

2. Второе занятие преследует приобретение некоторых навыков анализа. Предлагается проанализировать имеющуюся информацию, выделить функции и данные, распределить, структуризировать, сгруппировать, приоретизировать. Подготовить контекст решаемой задачи, построить контекстную диаграмму IDEF0. Здесь я следую главным образом [urlhttp://www.isuct.ru/~ivt/books/CASE/case8/sadt/gl22.htm]де Марко[/url]

3. Задание - выделение проблемного БП или просто БП для последующего анализа и изучения в индивидуальном порядке (в моем случае парой студентов в рамках группового на 6-8 человек задания). Здесь нужно выделить не очень сложный, но достаточной важный БП. Подготовить модель "как есть" для него, составить описание процессов и функций его составляющих, разработать модели IDEF0 и IDEF3 и подготовить образ решения  по типу Вигерса (смотри прицепку)

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

5. Построение информационной модели задачи - используется ERWin

6. разработка прототипа на Аксесс для понимания - а что получили?, и что бы хотелось еще получить?

Поскольку пункты с 2 по 6 еще в прогрессе, можно что-то изменить, сделать более точным и определенным. Прошу всех, кому это интересно высказываться и предлагать свои идеи.

192

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

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

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

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

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

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

далее

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

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

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

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

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

193

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

« : 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, методологий разработки ПО и систем.

194

Обучение / Дисциплина <Теория информационных процессов и систем> (ТИПИС)

« : 31 Августа 2007, 20:53:10 »

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

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

Несколько слов о том, как это предмет позиционируется в ГОС.

Теория информационных процессов и систем
Основные задачи теории систем; краткая историческая справка; терминология теории систем; понятие информационной системы; системный анализ; качественные и количественные методы описания информационных систем; кибернетический подход; динамическое описание информационных систем; каноническое представление информационной системы; агрегатное описание информационных систем. Операторы входов и выходов; принципы минимальности информационных связей агрегатов; агрегат как случайный процесс; информация и управление. Модели информационных систем; синтез и декомпозиция информационных систем; информационные модели принятия решений; возможность использования общей теории систем в практике проектирования информационных систем.

Всего на дисциплину отводится 170 часов, из них на аудиторные занятия примерно 80 часов. Т.е. самостоятельная работа достаточно большая.

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

Порядок лекций и их наполненность может несколько меняться. Это некоторый фиксированный вариант. Так, например, вопросы связанные с моделями данных приходится кратко читать по договоренности с преподавателем следующего курса по "Управлению данными".

Если в кратце, то я на лекциях даю
- небольшой обзор общей теории систем: цели, предмет, понятия, определения, практические выкладки, понятия системного анализа.
- исторические сведения о развитии АИС, понятия, определения, назначение и т.п.
- дальше несколько оторванно от предыдущего перехожу к структурным методам и рассматриваю ряд нотаций в рамках использования их для моделирования, анализа и т.п.

Хотелось бы кое-что изменить.
 
Во-первых, это должен быть некоторый вводный и обзорный курс, предваряющий более детальное изучение. Однако такого позволить себе к сожалению мы не можем, потому следует сделать этот курс более практичным и жестким.
Лучше всего, было бы отдельно читать ОТС и системный анализ, отдельно методы анализа и проектирования. 

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

В-третьих, может вообще исключить ОТС и системный анализа как самомостоятельный раздел и освещать его по мере необходимости?

В-четвертых, понятие ИС я хотел бы взять из лекций МГУ Когаловского. Вот содержание главы по ИС.

Глава 1.      Информационные системы и их функции           12
1.1. Что такое информационная система                                                      12
1.2. Моделирование реальности в информационных системах                   22
1.3. Функции информационных систем                                                         28
1.4. Разновидности информационных систем                                              40
1.5. Общие тенденции развития информационных систем                          48 Литература к главе 1                                                                                     59

Рассказано довольно внятно и интересно. Вот определение АИС, которое он дает:

Определение понятия «информационная система». Автоматизированной информационной системой называется комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства и информационные ресурсы, а также системным персонал и обеспечивающий поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей.

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

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

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

Напомню расклад основных дисциплин:

1-2 курсы Информатика, Всякие математики, Компьютерная графика, Программирование (паскаль), Вероятности и статистика, Информационные технологии, ну и общеобразовательные дисциплины

3 курс - как раз сейчас ТИПИС, функциональные мат модели, что-то еще не помню
3 курс (2 семестр) будет - ООП, моделирование систем, надежность ИС

все остальные дисциплины по ИТ уже 4 - 5 семестр.

195

Бизнес-анализ и Целеполагание / Главная, базовая, основная цель бизнеса

« : 27 Августа 2007, 21:13:40 »

Предлагаю начать дискуссию по цели бизнеса здесь.

Поиск в google на тему цель бизнеса привел меня к такой вот статье, которая возможно будет интересна и в рамках написания статьи уважаемым Boatman.
Ссылка на статью, вернее часть курса лекции - http://www.ecsocman.edu.ru/db/msg/203218.html.

Здесь сразу извлеку такую цитату:

Лекция 5. Цели бизнеса
А.Н.Дятлов, М.В.Плотников

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

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

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

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

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

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

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

относительно понятия миссия:

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

Другая цитата:

Цель любого бизнеса (выучите наизусть) - сделать мир лучше своим продуктом (или услугой). Дмитрий Честных

Если цель вашего бизнеса заключается в другом, пожалуйста, встаньте в стороне и курите бамбук

Она несколько агрессивна и не предполагает полемики. Однако и здесь мы не видим направленность именно на МАКСИМИЗАЦИЮ ПРИБЫЛИ.

Похожая дискуссия по поводу цели бизнеса велалсь например здесь: http://www.e-xecutive.ru/discussions/forum_11518/msg_51955_432814/

Другая цитата тоже интересная:

Цель бизнеса

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

Вот еще одна цитата:

Социально-этический маркетинг.

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

Итак мы можем суммируя сказать, что получение прибыли - есть действительная цель бизнеса, ее конечная и основополагающая цель! Даже если учесть перенос акцента на клиента бизнеса. Но так ли это на самом деле?

В словах Rocket есть очевидная правда.

Но и мысли Boatman мне импонируют.

Однако может быть их спор происходит в параллельных плоскостях?

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

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

цель бизнеса - достижение целей его основателя, удовлетворения его потребностей