46
Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)
« : 15 Сентября 2011, 11:29:30 »
Вкладка 'Править' после регистрации отображается.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
47
Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)
« : 14 Сентября 2011, 12:12:49 »
Александр, давайте уточним - вы предложили перенести предварительное обсуждение из ветки форума, я свой пост удалила. Если уж у нас началась дискуссия - могу вернуть и продолжим обсуждение здесь для данного конкретного случая.
48
Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)
« : 14 Сентября 2011, 10:40:50 »
Пост пока удален по согласованию с Александром Белиным.
49
Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)
« : 08 Сентября 2011, 14:00:13 »
Change Control Board
Я бы предложила 'Совет по управлению изменениями' ('Совет директоров' - корректно, но 'Совет по развитию малого бизнеса')
или 'Группа управления изменениями'.
Я бы предложила 'Совет по управлению изменениями' ('Совет директоров' - корректно, но 'Совет по развитию малого бизнеса')
или 'Группа управления изменениями'.
50
Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)
« : 05 Сентября 2011, 11:40:44 »
Task - я бы предложила - 'задача'.
А вообще такая проблема встречается часто, и в каждой конкретной ситуации, наверно, придется решать ее отдельно. Возможно, в ряде случаев удастся выработать некое единообразие.
Кстати, как будем переводить термин 'technique' в рамках нашей темы? Методика, технология или метод?
А вообще такая проблема встречается часто, и в каждой конкретной ситуации, наверно, придется решать ее отдельно. Возможно, в ряде случаев удастся выработать некое единообразие.
Кстати, как будем переводить термин 'technique' в рамках нашей темы? Методика, технология или метод?
51
Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)
« : 02 Сентября 2011, 12:13:26 »
Термины K-L-M-N скинула на почту.
52
Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)
« : 26 Августа 2011, 09:30:21 »
Готова принять участие в переводе Глоссария. Назначайте букву 
53
Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)
« : 22 Августа 2011, 16:05:49 »Цитировать
ДеятельностьНачинания? хотя тоже не самый лучший вариант. А нет ли там определений - что есть 'initiative' и 'process'?
Единица работы выполненная в рамках инициативы (может подскажете вариант получше?) или процесса
А Ваше начинание - идея хорошая.
54
Задачи студентов / Re: Диаграмма классов и вариантов использования: нужна помощь!
« : 20 Июня 2011, 17:02:35 »
По вариантам использования.
В use case обычно отображаются цели действующего лица, т.е, то, чего действующее лицо хочет достичь при работе с системой. Деталей реализации вроде подключения к БД там быть не должно. Предположительно, у Вас вырисовывается два действующих лица
1. Пользователь
2. Программист (лучше обозвать как-нибудь по-другому, 'служба сопровождения', что ли...)
Варианты использования для Пользователя
- Добавить изображение
- Поставить контрольную точку
- Найти изображение /*скажем, по критериям поиска*/
- ....
По поводу второго действующего лица не все ясно. Будут ли некие действия, которые Ваш 'Программист' будет совершать средствами системы? Ну, архивирование какое-нибудь, либо удаление старых изображений? Если под сопровождением имеется в виду, что разработчик (он же аналитик, он же служба сопровождения, он же тестировщик в одном флаконе) залезает непосредственно в базу и ручками что-то там
правит - это на диаграмме ВИ отображать не стоит.
По классам.
Класс в нотации UML на основе приведенного кода будет выглядеть как квадратик, в котором написано MainWindow, с перечислением методов ниже. Такие детали реализации вряд ли есть смысл изображать на диаграмме классов - это если только для отчетности надо...
Скорее всего, Вам нужно выделить сущности предметной области (кстати, Вы не уточнили, что это за область) и прикинуть, как они связаны друг с другом.
Слоты и сигналы QT - технически просто методы соответствующих классов. Но поскольку они несут вполне определенную смысловую нагрузку (связь между объектами), эти классы явно должны быть соединены ассоциацией.
Т.е, рисуете в UML классы и ассоциации между ними, а на уровне кода эти ассоциации будут выражены механизмом слотов-сигналов.
В use case обычно отображаются цели действующего лица, т.е, то, чего действующее лицо хочет достичь при работе с системой. Деталей реализации вроде подключения к БД там быть не должно. Предположительно, у Вас вырисовывается два действующих лица
1. Пользователь
2. Программист (лучше обозвать как-нибудь по-другому, 'служба сопровождения', что ли...)
Варианты использования для Пользователя
- Добавить изображение
- Поставить контрольную точку
- Найти изображение /*скажем, по критериям поиска*/
- ....
По поводу второго действующего лица не все ясно. Будут ли некие действия, которые Ваш 'Программист' будет совершать средствами системы? Ну, архивирование какое-нибудь, либо удаление старых изображений? Если под сопровождением имеется в виду, что разработчик (он же аналитик, он же служба сопровождения, он же тестировщик в одном флаконе) залезает непосредственно в базу и ручками что-то там
правит - это на диаграмме ВИ отображать не стоит.
По классам.
Класс в нотации UML на основе приведенного кода будет выглядеть как квадратик, в котором написано MainWindow, с перечислением методов ниже. Такие детали реализации вряд ли есть смысл изображать на диаграмме классов - это если только для отчетности надо...
Скорее всего, Вам нужно выделить сущности предметной области (кстати, Вы не уточнили, что это за область) и прикинуть, как они связаны друг с другом.
Слоты и сигналы QT - технически просто методы соответствующих классов. Но поскольку они несут вполне определенную смысловую нагрузку (связь между объектами), эти классы явно должны быть соединены ассоциацией.
Т.е, рисуете в UML классы и ассоциации между ними, а на уровне кода эти ассоциации будут выражены механизмом слотов-сигналов.
55
Проектирование / Re: Проектирование ИИ бота
« : 09 Февраля 2011, 17:27:06 »
Насколько могу судить, ИИ - если его серьёзно обсуждать - тема очень сложная, обширная, требующая хорошей математической подготовки. Но у Вас на данном этапе, видимо, скорее учебная задача, гимнастика ума своеобразная.
Обратимся к Вашему самообучающемуся роботу...
Вот первый этап его обучения. Ну пример "день" - ладно. А как Вы будете делить на два, скажем, такое понятие, как "компьютер"? Или "дерево"? Или, скажам, Ваш "смеющийся кирпич" - у понятия "смеющийся" какие числовые характеристики?
Скорее стоит вводить некий набор атомарных понятий - но это только для ограниченной предметной области возможно.
Обратимся к Вашему самообучающемуся роботу...
Вот первый этап его обучения. Ну пример "день" - ладно. А как Вы будете делить на два, скажем, такое понятие, как "компьютер"? Или "дерево"? Или, скажам, Ваш "смеющийся кирпич" - у понятия "смеющийся" какие числовые характеристики?
Скорее стоит вводить некий набор атомарных понятий - но это только для ограниченной предметной области возможно.
56
Для всех / Re: Поможет ли UML?
« : 20 Января 2011, 11:30:22 »Цитировать
Нет ли достойной, но более простой альтернативы?Есть, конечно. Microsoft Word, например )
Если в команде нет энтузиазма по поводу использования UML, может, и не стоит его активно навязывать. Описывайте задачу текстом, и сопровождайте его диаграммами по возможности. Постепенно команда привыкнет и перестанет бояться аббревиатуры UML, а Вы оцените, удобно ли Вам такое представление информации.
57
Для всех / Re: Поможет ли UML?
« : 19 Января 2011, 11:09:50 »
Вы знаете, сам по себе UML, конечно, не серебряная пуля. Но раз уж у Вас возникла мысль, что пора бы описывать какие-то аспекты системы в виде, отличном от кода, и более понятном участникам проекта, не являющимся программистами, то вполне удобно использовать для этого UML.
Для разработки, имхо, стоит начать с диаграмм классов и последовательности (sequence).
Для разработки, имхо, стоит начать с диаграмм классов и последовательности (sequence).
58
Обсуждение статей / Re: Как распознать «бобра»
« : 24 Декабря 2010, 16:46:07 »
Elf, такое развитие событий, конечно, гротеск.
Разумеется, термины предметной области нужно изначально описать так, чтобы эти определения соответствовали действительности и были однозначно поняты всеми заинтересованными лицами.
Но не буду спорить.
Разумеется, термины предметной области нужно изначально описать так, чтобы эти определения соответствовали действительности и были однозначно поняты всеми заинтересованными лицами.
Цитировать
аналитик при проектировании системы всегда согласует разработанные требования с экспертами, и тогда изложенного сценария не будет.А вот это утверждение представляется мне немного утопичным.
Но не буду спорить.
59
Обсуждение статей / Re: Как распознать «бобра»
« : 23 Декабря 2010, 17:33:09 »
Статья, несомненно, полезная и познавательная. Но хотелось бы сделать несколько замечаний по поводу употребления в данном контексте слова "бобёр". Точнее, хотелось бы обратить внимание на важность корректного использования наименований - даже в тех вопросах, где изначально это представляется не очень существенным.
Употребление неточной либо неполной терминологии неизбежно приводит к взаимному непониманию. Если речь идет об IT-индустрии, можно смело утверждать, что пренебрежительно относясь к терминам, мы закладываем мину под проект на самой ранней стадии его развития.
Итак, о бобрах. Какие же сведения о них можно почерпнуть в открытых источниках информации?
Вот пара цитат.
Список можно было бы продолжить. Заметим, что в вышеприведенных отрывках подчеркивается ум и трудолюбие этих животных, что совсем не соответствует образу "бобра" из статьи.
Можно возразить - а какая, в сущности, разница? Главное, в данном конкретном случае вроде бы все всё домыслили и поняли так, как нужно.
Но может быть, это не последняя наша встреча с бобрами.
Предположим, предполагается создание ИС, предназначенной для прогнозирования поведения диких животных в определенном ареале. После прочтения обсуждаемого документа у нас сформировался стереотип бобра как ленивого паразита, думающего исключительно о том, как бы что заполучить на халяву. Именно на эту точку зрения могут встать авторы системы, что наложит свой отпечаток еще на стадии анализа, и, разумеется, эти же соображения плавно перейдут в проектирование и реализацию.
Далее...
ИС готова. Запустили моделирование экосистемы леса.
Бобры ленятся. Сидят, сложив лапы, ухмыляются. Не валят деревья, не строят плотины. Нет водных разливов. Рыба исчезла. Нет поваленных деревьев. Из-за этого зайцам и копытным стало нечего есть, и они передохли.
Устойчивость биогеоценоза нарушена. Хищникам тоже стало нечего есть, они перебрались поближе к населенным пунктам и нападают на домашний скот и человека.
На основании сделанного прогноза была разработана программа завоза в регион зайцев, чтобы хищники не оголодали. Их завезли, и они сожрали посевы - поскольку на самом-то деле благодаря полезной деятельности бобров их было много с самого начала.
Так ошибки на этапе анализа приводят к дорогостоящим последствиям. И не последнюю роль здесь играет легкомысленное обращение с терминами.
Кстати, интересно возникновение этого сленгового словечка - "бобер" (точнее, "бобр"). Происхождение его не вполне ясно. Может быть, это неудачный перевод с английского, прижившийся в HR, а в оригинале использовано название совсем другого животного?
Употребление неточной либо неполной терминологии неизбежно приводит к взаимному непониманию. Если речь идет об IT-индустрии, можно смело утверждать, что пренебрежительно относясь к терминам, мы закладываем мину под проект на самой ранней стадии его развития.
Итак, о бобрах. Какие же сведения о них можно почерпнуть в открытых источниках информации?
Вот пара цитат.
Цитировать
"Из всех диких зверей ...самые диковинные и умные, несомненно, бобры...http://www.lukoshko.net/sokol/sok11.shtml
...умные бобры умеют строить на реках высокие плотины. Они поднимают воду в реке, возводят на берегах целые посёлки.... Я изумлялся инженерному мастерству и уму бобров... По-видимому, строительная дружная работа производилась всем обществом бобров. Я не сомневаюсь, что умные и трудолюбивые бобры, как и многие другие дикие животные, могли бы стать доверчивым и близким другом человека".
Цитировать
"Активны бобры ночью и в сумерках. Летом они выходят из жилищ в сумерках и трудятся до 4-6 часов утра. Осенью, когда начинается заготовка кормов на зиму, трудовой день удлиняется до 10-12 часов.http://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%B1%D0%B5%D1%80
Появление бобров в реках и особенно постройка ими запруд оказывает благоприятное воздействие на экологию водных и приречных биотопов".
Список можно было бы продолжить. Заметим, что в вышеприведенных отрывках подчеркивается ум и трудолюбие этих животных, что совсем не соответствует образу "бобра" из статьи.
Можно возразить - а какая, в сущности, разница? Главное, в данном конкретном случае вроде бы все всё домыслили и поняли так, как нужно.
Но может быть, это не последняя наша встреча с бобрами.
Предположим, предполагается создание ИС, предназначенной для прогнозирования поведения диких животных в определенном ареале. После прочтения обсуждаемого документа у нас сформировался стереотип бобра как ленивого паразита, думающего исключительно о том, как бы что заполучить на халяву. Именно на эту точку зрения могут встать авторы системы, что наложит свой отпечаток еще на стадии анализа, и, разумеется, эти же соображения плавно перейдут в проектирование и реализацию.
Далее...
ИС готова. Запустили моделирование экосистемы леса.
Бобры ленятся. Сидят, сложив лапы, ухмыляются. Не валят деревья, не строят плотины. Нет водных разливов. Рыба исчезла. Нет поваленных деревьев. Из-за этого зайцам и копытным стало нечего есть, и они передохли.
Устойчивость биогеоценоза нарушена. Хищникам тоже стало нечего есть, они перебрались поближе к населенным пунктам и нападают на домашний скот и человека.
На основании сделанного прогноза была разработана программа завоза в регион зайцев, чтобы хищники не оголодали. Их завезли, и они сожрали посевы - поскольку на самом-то деле благодаря полезной деятельности бобров их было много с самого начала.
Так ошибки на этапе анализа приводят к дорогостоящим последствиям. И не последнюю роль здесь играет легкомысленное обращение с терминами.
Кстати, интересно возникновение этого сленгового словечка - "бобер" (точнее, "бобр"). Происхождение его не вполне ясно. Может быть, это неудачный перевод с английского, прижившийся в HR, а в оригинале использовано название совсем другого животного?
60
Задачи студентов / Re: Давайте подискутируем насчет модели
« : 08 Декабря 2010, 12:29:53 »
Вы так и не уточнили границы системы. Будем строить догадки. По косвенным признакам можно предположить, что все-таки планируется делать некую систему моделирования бизнес-процессов автопарка... Ну с целью, скажем, иметь возможность прокрутить в режиме ускоренной перемотки работу автопарка за сутки и спрогнозировать выручку.
В любом случае введите класс Заказ или Рейс - перенесите сумму, время, пункты отправления и назначения туда. Многое станет проще.
Пока не улавливаю особого смысла ввода класса Autopark, но если развивать дальше тему моделирующей системы - может, он и появится.
В любом случае введите класс Заказ или Рейс - перенесите сумму, время, пункты отправления и назначения туда. Многое станет проще.
Пока не улавливаю особого смысла ввода класса Autopark, но если развивать дальше тему моделирующей системы - может, он и появится.