3976

Системный Анализ и Требования / Re: Чисто практический вопрос

« : 23 Июля 2008, 00:37:37 »

Эд, если я правильно понимаю, то у вас ситуация следующая:
Начальство не устраивает качество продукта, а не качество процесса. 
И еще у меня сложилось впечатление, что ваше руководство считает, что для разработки и тестирования большого ума не надо,

Irr, НИЧЕГО подобного я тут не говорил (исключая архитектуру), я не перехожу на конкретику, я говорю об общем. Я не говорю о чем-то моем. Тем более я не могу знать мысли начальства. Т.е. don't be hurry in your conclusions.

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

3977

Обучение / Re: Статья: Создание эффективной инженерной документации

« : 23 Июля 2008, 00:01:44 »

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

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

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


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

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

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

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

3978

Системный Анализ и Требования / Re: Чисто практический вопрос

« : 22 Июля 2008, 21:56:54 »

ИМХО надо стремиться к хорошему, одному тебе систему не сломать

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

Цинично добавлю: очень многое зависит от руководства. Если руководство устраивает текущий процесс

А если не устраивает? А если проблема в ранее принятом стиле работы, инерции, ошибках проблемах архитектуры? Хотя тут слышал такое высказывание: "да причем тут архитектура, не в архитектуре дело, у всех эти архитектуры одинаковые"

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

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

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

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

Даже после того как описал требования в текстовом виде и далее по нему составил схему, то видишь какой бред ошибки написаны в тексте

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

3979

Обучение / Re: Статья: Создание эффективной инженерной документации

« : 22 Июля 2008, 21:30:13 »

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

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

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

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

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

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

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

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

Текст предельно однозначен

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

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

Непротиворечит ли данное утверждение сделанному анализу текста, как однозначного?

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

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

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

3980

Обучение / Re: Статья: Создание эффективной инженерной документации

« : 22 Июля 2008, 19:56:12 »

Благодарю всех принявших участие за море отзывов и конструктивной критики

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

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

3981

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

« : 21 Июля 2008, 23:51:08 »

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

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

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

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

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

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

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

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

3982

Sparx / Re: Контекстная диаграмма в ЕА

« : 21 Июля 2008, 16:13:41 »

Эд, м.б. выложить тогда в файловый архив эту книгу.

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

3983

Sparx / Re: Контекстная диаграмма в ЕА

« : 20 Июля 2008, 17:44:02 »

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

3984

Системный Анализ и Требования / Re: Хорошие требования vs Сырые требования

« : 20 Июля 2008, 17:16:44 »

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

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

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

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

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

3985

UML SysML и пр. / Re: Ассоциации + квалификаторы

« : 20 Июля 2008, 17:07:52 »

Связь - экземпляр ассоциации.
Что такое "экземпляр связи" можно только догадываться.

Ночные посиделки точно влияют на корректность Спасибо исправил

3986

Sparx / Re: Контекстная диаграмма в ЕА

« : 20 Июля 2008, 01:34:23 »

А как показывать, что "выход одной есть вход другой" в этой нотации на диаграмме анализа?

Вообще термин нотация Эрриксона-Пенкера не совсем корректна. Скорее нужно говорить о расширении UML. Просто данные авторы попытались расширить UML средствами моделирования бизнес-процессов.

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

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

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

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

3987

UML SysML и пр. / Re: Ассоциации + квалификаторы

« : 20 Июля 2008, 01:19:18 »

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

Замечание справедливое. Спасибо. Исправил ошибку

Квалификатор никак не связан с ОО, а пришел из схем баз данных.

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

3988

UML SysML и пр. / Re: Ассоциации + квалификаторы

« : 19 Июля 2008, 22:10:23 »

Коллеги.

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 »

Спасибо за ответ. Однако насколько я понимаю, кооперация не ограничивается только шаблонами проектирования? Вы сами сказали, что возможны и поведенческие моменты?

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