Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Galogen

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »
3751
Можете мне хотя бы намекнуть, каким образом можно описать цель "Учесть товары, переданные контрагенту"
Кто лучше вас может ответить на этот вопрос? Но я попробую.

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

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

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

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

3752
To bas:
не совсем понимаю смысл выражения "Концепция системы". Не могли бы пояснить? Имеется в виду общие требования?
Предположим Вы хотите качать нефть, что нужно? какие действия предпринять, кто участвует, да просто оценить а будет ли это целесообразно. Кроме того дать всем заинтересованным лицам представление о задачи

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

3753
Ногами сильно не пинайте. Я только встал на путь анализа и проектирования. До этого заказы мы выполняли "по наитию".
То что ЮзКейс - это цель - я понял из книги Коберна (хотя книга далась тяжело). Но почему не возможна декомпозиция цели - я не понимаю. Допустим Цель - "Учет товаров переданных контрагенту". Что бы достичь данной цели пользователь должен 1."Передавать товары контрагенту" и т.д.
Чем не декомпозиция?
Цель декомпозируема - это факт. Но ВИ не функция, ВИ отражает цель пользователя, а не является ее сам по себе. ВИ это способ использования системы для достижения ЦЕЛИ. Естественно возможны варианты. Эти варианты и описывает ВИ. Такие варианты называются для ВИ сценариями. Сценарий может быть успешным - цель достигнута, и не успешным - цель не достигнута или достигнута лишь частично. ВИ - это соглашение о том, как пользователь использует систему, чтобы достичь своих целей - в данном случае выполнить свои функциональные обязанности. Можно ли назвать целью Напечать отчет? А зачем? не есть ли отчет результат достижения цели?
ВИ - можно сказать транзакция - она или выполняется или не выполняется. В ходе транзакции выполняются разные ФУНКЦИИ, обладающие АЛГОРИТМАМИ. Вот функции можно декомпозировать, а как декомпозировать ВИ - на шаги? А разве шаг есть часть цели (подцель)? Конечно нет!

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

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

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

Бизнес ВИ не декомпозируется - а реализуется через часть пользовательских ВИ, задает для них контекст

Цитировать
Пока писал ответ - пришла в голову мысль: "А можно ли назвать "Учет товаров переденных контрагенту" целью?
Цель имеет два состояния - (ничего не напоминает) соответственно - задайте себе вопрос достигнута цель: Учета товаров переданных контрагенту или нет. Каков критерий измерения достижения цели?
Или задайте вопрос, а зачем учитывать товары переданные контрагенту, каков интерес?

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

3754
1. Как Вы понимаете существуют разные уровни рассмотрения вариантов использования и область контекста.
2. ВИ не декомпозируются - это будет неправильно, но можно декомпозировать цели
3. Естественно начинать сверху вниз от целей бизнеса к целям пользователей
4. Естественным инструментом декомпозии в UML является пакет
5. Подсистема разбивается еще на ряд подсистем, задач, модулей, компонентов
6. Для каждого такого деления выстраивается модель взаимодействия, которая включает описание ВИ, причем диаграмма тут имеет последнее значение
7. Вариант использование - это элементарный бизнес-процесс производимый одним человеком в одном месте за один сеанс деятелности и приводящий к ощутимому результату, изменению состояния системы
8. ВИ описывает потребную с точки зрения пользователй функциональность системы
9. Логика работы такой функциональности может описываться диаграммами деятельности в первую очередь, а такжде системными диаграммами последовательностей во вторую

Кстати документо оборот лучше описыать с помощью DFD имхо

3755
Умница

3756
Интересно, как подобные задачи другие решали.
Ага :) Мои слова вас уже притомили :)

Цитировать
Не я ж один такой одинЭснег, кто задумался над проблемой документирования собственной работы.
А вы поищите темы на форуме, я и другие подобные темы поднимали.

Да с одной стороны есть инструмент со своими ограничениями, возможностями, +  и  -

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

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

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

Тогда надо иметь внятный документ базовых моделей 1С

Модель чего хотелось бы

Модель разницы

А?

3757
Спасибо. С Вашей презентацией я ознакомился. Но вопросов пока больше чем ответов.
Так и задавайте их! Прямо здесь

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

3758
Задача - сделать максимально простую документацию, но достаточную для всех сторон :)) Мне интересно каким образом документируются небольшие проекты в случае штатных разработчиков? Не пишется же отчет об обследовании, ведь работники сами прекрасно представляют организацию.. Как мне кажется: Надо просто задокументировать цели, пользовательские пожелания и задачи.
Как учат нас the best practices в основе видение или концепция. Это и бизнес-план, и артефакт, призванный как раз дать всем ясное представление о том, что нужно делать, каковы стратегические и тактические цели, кто заитересован в проекте и какие общие нужды имеет.

Такми образом можно набросать Видение и спецификацию дополнительных средств.

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

По сути Вы и сами все написали


3759
Здравствуйте.

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

Цитировать
Например: месяц пишем подсистему CRM, потом месяц подсистему "Управление инструментами" и т.д. Разработать общее ТЗ/документ требований и общую модель системы не возможно.
А что понимать под общим ТЗ? Если нет понимания чего в общем делаем, а есть, как я понимаю, поэтапное внедрение функциональных подсистем, просто на одной платформе и разработчки тоже один?
Также интересно узнать, что Вы вкладываете в понятие общая модель системы и невозможность ее создания?

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

В общем формировали бизнес-процессы в BPMN - вполне понимаемые стороной заказчика, устраивали презентации и собрания.

Что касается стороны аналитик-разработчик, то тут проще - это внутренний мир и способ представления избирается привычный удобный. По своей схеме - по-моему - это нечто из советских времен, называемые постановками задачи: входная информация, выходная информация, предложения по экранным формам. Почти информационное обеспечение в внемашинным ИО и внутримашинным ИО :).

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


3761
Так все-таки трассировка - это прослеживаемость одно через другое, или же все-таки вытекание одного из другого. Если последнее - то, это, по-моему, и есть зависимость . Нет?

3762
Очень интересно.

Денис удачи и вдохновения!

3763
Я тоже вставлю свой алтын.

Трассировка или прослеживаемость. Происходить от английского trace III.
Среди переводов мы видим:
следовать, идти по следам
проследить, установить
прослеживаться, восходить

Такми образом прослеживаемость может быть разного направления как прямого, так и обратного.

Направление прослеживаемости можно понять относительно некоего требования или артефакта смотри вложение

3764
Реализация / Реализация шаблона MVC
« : 21 Октября 2008, 22:49:10 »
Я уже имел консультацию по этому вопросу. Мне было сказано, что я не понимаю назначение MVC, вполне возможно. Даже наверняка. Да нет же совершенно не знаю :) Но хочу знать.

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

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

Задачка следующего типа:
пусть имеется клиент. который делает в какой-то он-лайн системе заказы. Не в даваясь во все возможные ситуации ограничимся двумя часто возникающими вариантами.
1. авторизация (без авторизации можно только посмотреть главную страницу, ну поизучать каталог, почитать сопутсвующую информацию, для создания же заказа нужно регистрироваться и потом уже авторизироваться)
2. создание нового заказа.

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

При авторизации:
Пользователь вводит логин и пароль
Система узнает пользователя, приветствует и предоставляет ему соответствующий доступ

Возможный сценарий реализации может выглядеть так:
1 Пользователь вводит url сайта в командную строку браузера.
2. браузер отображает Главную страницу сайта
3. Пользователь вводит логин и пароль в поля Формы авторизации и нажимает кнопку Войти
4. Браузер пользователя отправляет http- запрос, содержащий введенные значения логина и пароля, Web-серверу
5. Web-сервер перенаправляет запрос соответствующему Скрипту (по сути методу некоего класса-контроллера)
6. Класс-контроллер, выполняя метод, инстанцирует объект Пользователь с параметрами Логин и Пароль:
    если такой объект существует в БД, тогда запускается метод получить данные Клиента
    если такого объекта нема, создается сообщение-уведомление
7. Получив данные Класс-контроллер отправляет пользователю на браузер соотвествующую страницу сайта

Как полагаете пойдет такое?

Как это может выглядеть в виде некоего кода?

1. как я понимаю на action формы будет просто передача параметров нужному скрипту
2. в скрипте инстанциируется контроллер, который получает параметры и запускает метод, который
3. инстанциирует объект бизнес-логики, который
4  посылает запрос в БД
и в обратном порядке?

В общем чего не так? Не слишком все кудряво?

3765
Виталий, если не трудно, переведи на английский и я закину в поддержку. Пускай отрабатывают пока я имею право.

Хотя я тут поискал и кое что нашел.

К примеру у тебя есть модель требований -
1.выделяешь этот пакет
2. идешь в ProJect/Documentation
3. Там играешься Implementation Details или Dependences Details

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »