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

×


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

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


Сообщения - 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 »
3976
Эд, если я правильно понимаю, то у вас ситуация следующая:
Начальство не устраивает качество продукта, а не качество процесса. 
И еще у меня сложилось впечатление, что ваше руководство считает, что для разработки и тестирования большого ума не надо,
Irr, НИЧЕГО подобного я тут не говорил (исключая архитектуру), я не перехожу на конкретику, я говорю об общем. Я не говорю о чем-то моем. Тем более я не могу знать мысли начальства. Т.е. don't be hurry in your conclusions.

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

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

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

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


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

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

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

Вот как-то так...

3978
ИМХО надо стремиться к хорошему, одному тебе систему не сломать
Ой, Саня, нет у меня такой задачи и роли. Никто не уполномачивал, да и кто я такой? Препод с 14 летним опытом, исследователь с 17 летним опытом. Я же по определению только и могу - учиться, изучать. А в бизнесе, что нужно? Велью и сразу!

Цинично добавлю: очень многое зависит от руководства. Если руководство устраивает текущий процесс
А если не устраивает? А если проблема в ранее принятом стиле работы, инерции, ошибках проблемах архитектуры? Хотя тут слышал такое высказывание: "да причем тут архитектура, не в архитектуре дело, у всех эти архитектуры одинаковые"

Я сейчас один умный вещь скажу, только ты не обижайся. :) Это нужно в первую очередь не заказчику и даже не компании-разработчику, а команде, создающей продукт.
А чего на умный вещь обижаться, если умная человек она говорит :)
Да понимаю я, что требования мине нужно в первую голову, и даже не заказчику...

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

Даже после того как описал требования в текстовом виде и далее по нему составил схему, то видишь какой бред ошибки написаны в тексте :)
Если ты в пример ставишь присланный как-то тобой документ, то я тебя оччень понимаю. Но, однако ёопытрст получаешь:)

3979
Цитировать
Любой опытный инженер, аналитик или менеджер знает простые правила создания эффективной документации, но они достались ему по крупицам из разных источников и собственного (в том числе и негативного) опыта.
А каков критерий опытности? Я, например, знаю, что документация порой не ведется вообще, или только некая промежуточная, которая особо не хранится. Порой даже слышу утверждения, что никой документации вести не нужно вообще, кроме той, которую передают заказчику.

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

Цитировать
Надеюсь, читатель, достаточно убежден в том, что отсутствие документирования, мягко говоря, не всегда ведет к успеху.
Мне, кажется, я убежден. Хотя убеждение есть чисто теоретическое. Правда понял, что устные распоряжения могут просто потеряться в глубинах памяти, даже если оно - это распоряжение было высказано пять минут назад. Так что приницип - то, что не задокументировано, считай, что не было.
Однако ведь документировать можно не только документацией. К примеру системы поручений, где тебе выставляют некое поручение, задачу и т.п. Оно ведь может служить аналогом документации?

Цитировать
- не включить в шаблоны документов ничего лишнего,
может не включить в шаблон документов лишнего?

Цитировать
Текст предельно однозначен
А правильно ли так утверждать? Как может быть однозначен текст при неоднозначности составляющих его словоформ?
А умение писать, стиль, простота языка, понятность? Или имеется в виду жестко структурированный текст?

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

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

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

Предлагаю начать например с тестовых сценариев....

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

Вот провожу отпуск по университету, работая на второй работе. Чувствуйтся там есть проблемы с эффективной документацией. Меня сейчас живо волнует проблема документации по тестированию

3981
Коллеги, у меня, так сказать, чисто практический вопрос. Хотя, можно подумать, что тут задают вопросы не чисто практические:) Конечно, все задают вопросы своей практики.

Однако я отвлекся. Здравствуйте.

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

К чему это я. Да все о требованиях родимых. Пишем требования по ТЗ, пишем списками, пишем фичами, пишем вариантами использования, пишем как придется.

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

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

Такой вопрос. Скажите у Вас такая же практика? Вы примерно также устраиваете свой процесс разработки? Это вполне нормально? Если ненормально, то как лучше строить процесс?

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

3982
Sparx / Re: Контекстная диаграмма в ЕА
« : 21 Июля 2008, 16:13:41 »
Эд, м.б. выложить тогда в файловый архив эту книгу.
Саня я вчера полвечера пытался.
Сначал мне выдало собщение, что файл превышает допустимый размер, потом я пытался его разбить на кусочки и вложить на форуме - не удалось :(

3983
Sparx / Re: Контекстная диаграмма в ЕА
« : 20 Июля 2008, 17:44:02 »
Скажите свой почтовый адрес - я бы Вам выслал книгу ЭриксонаПенкера, тогда бы Вы сами поняли все из первых рук.

3984
Итерационная разработка предполагает циклический подход. Однако во всех таких подходах, требования итерационно не уточняются, а итерационно вовлекаются. Т.е. на первой стадии следует выделить самые самые требования при чем их должно быть не больше 10%. Ларман в своей книге "Применение UML и шаблонов проектирования" рассматирвает итерационный подход на примере вариантов использования. Т.е. вначале очень важно определить список требований (читай ВИ), ранжировать их и отделить самые самые, и уже их детально проработать.

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

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

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

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

3985
Связь - экземпляр ассоциации.
Что такое "экземпляр связи" можно только догадываться.
Ночные посиделки точно влияют на корректность :) Спасибо исправил :)

3986
Sparx / Re: Контекстная диаграмма в ЕА
« : 20 Июля 2008, 01:34:23 »
А как показывать, что "выход одной есть вход другой" в этой нотации на диаграмме анализа?
Вообще термин нотация Эрриксона-Пенкера не совсем корректна. Скорее нужно говорить о расширении UML. Просто данные авторы попытались расширить UML средствами моделирования бизнес-процессов.

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

Кроме того насколько я понимаю авторы позаимствоали форму процессов у методики VAC Value Added Chain, т.е. когда такие-вот флажки идут друг за другом, образуя цепочки добавленной стоимости.

Авторы добавили события, чего нет в IDEF0, и чего нет явно в диаграммах активности прошлых версий UML.

Потому нет ничего сложного в передачи управления с выхода на вход.

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

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

3988
Коллеги.

1. Давайте производить корректное цитирОвание для начала. И Budda и Денис - Вам следует сначала познакомится со справкой на использование форума. Сделайте одолжение.

2. Насчет квалификатора. Квалификатор создает квалифицированную ассоциацию.

Qualifier - qualify + er и определитель; уточнитель, спецификатор

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

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

Типичным примером можно назвать такой пример:
смотри рисунки


3989
Sparx / Re: Контекстная диаграмма в ЕА
« : 18 Июля 2008, 19:47:10 »
Telemed, да мне кажется можно изобразить так как хочется, лишь бы было понятно.

Насчет 1 д. Если ИС уже имеется и внедрена, и используется, то конечно ее нужно построить(включить) в контекст. Если же ИС предполагется сделать - то имхо в контекст ее включать как бы и не надо, хотя если изобразить контекст в стиле Захмана или TOGAF, почему бы и нет:)

Как бы сказал Boatman- а какова цель, кков ожидаемый или идеальный результат.

Насчет 2 д. Все таки на входе у Вас показаны события - такими флажками. А события есть проишествия проишедшие, которые собственно и вызвали весь дальнейший сыр бор.
Далее имхо процессы разного уровня у вас отображены. Диагностические исследования и Передача данных.
И, знаете, процесс не совсем видно: Анализ данных - врачебное заключение, потом врачебное заключение как событие (при этом получаемое) и идет Телеконсультация. Если собственно телеконсультация не может состояться до диагностических процедур и шедствует за ними - может так и показывать? Выход одной есть вход другой?

3990
Нововведения / Re: Популярно об UML 2.0
« : 18 Июля 2008, 10:08:17 »
Спасибо за ответ. Однако насколько я понимаю, кооперация не ограничивается только шаблонами проектирования? Вы сами сказали, что возможны и поведенческие моменты?

Еще интересно понять возможности использования разных дополнительных элементов типа портов, частей и т.п.

Страницы: « 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 »