481

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 11 Июня 2008, 14:20:36 »

Еще, в догонку -- очень интересная вещь http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/12.pdf

482

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 11 Июня 2008, 14:09:44 »

Юра,
Еще бы не плохо если бы ты сказал эти "мерительные" показатели, или сказал бы где почитать ...

Списка всех показателей на память не помню ... но например тот же PSP\TSP дает много метрик -- можно наковырять. Ряд KPI можно подсмотреть в COBIT.

еще можно посмотреть тут http://satc.gsfc.nasa.gov/support/PNSCQ_OCT98/requirements_testing_and_metrics.html

еще тут http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/11.pdf

Еще можно посмотреть эту книгу - Software Testing Fundamentals: Methods and Metrics
by Marnie L. Hutcheson ISBN:047143020X John Wiley & Sons © 2003 (408 pages)
Там есть раздел по метрикам относящихся к тестированию, но часть из них вполне применима как показатели качества ПО.

Еще можно кое-что выковырять отсюда Software Metrics: A Guide to Planning, Analysis, and Application
by C. Ravindranath Pandian   ISBN:0849316618
Auerbach Publications © 2004 (312 pages)

Далее, тут есть интересные моменты: Practical Measurement in the Rational Unified Process by Doug Ishigaki
Sr. Technical Marketing Engineer Rational Software and Cheryl Jones. Это из Rational Edge статья, кажись за 2003 год.

483

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 13:54:14 »

Нужно добавить еще один момент -- требования по сути это scope проекта. Когда scope неясно очерчен, то не понятно где заканчивается проект, что чревато особенно при fixed price ...
А вообще забавная ситуация -- многие ИТ-руководители не могут посчитать бизнес-value от ИТ у себя в компании, но требуют этого от своих поставщиков тулов и услуг :-). А вообще, считать экономический эффект от внедрения процессов можно только если у компании вообще есть статистические данные -- например то же распределение дефектов ПО по их причинам, средняя стоимость одного дефекта ... и вообще как эта компания измеряет качество и какие заданные параметры качества ПО у нее есть. Если компания не задумывается об измерении качества ПО, не задумывается о метриках своей работы как таковых (т.е. говорим что у компании низкий уровень зрелости), то скоре всего ей не нужно улучшать процессы в принципе. А если в компании сидит 5 программистов и нет ни одного аналитика, то разработчикам бесполезно предлагать работу с требованиями. Максимум, что им можно предложить, так это использовать bag tracker.

484

Варианты Использования (Use Case) / Re: Варианты использования для средств графического проектирования

« : 09 Июня 2008, 10:44:10 »

Если цель пользователя создать шаблон отчета, и он может размещать строго определенный палитрой набор виджетов на бланк. И при этом есть ограничения (например в определенные секции шаблона отчета могут быть размещены только определенные виджеты). То, даже если писать для этого случая юзкейс, я бы написал просто casual юзкейс, в котором бы сказал, что создавая отчет юзер может размещать на бланке виджеты (указать ссылку на список виджетов) в соответствии с бизнес правилами (ссылка на бизнес-правила). Value то же, усилий IMHO при чтении и создании такого юзкейса меньше, чем в предложенном Сашей варианте. Manage your energy (c) A. Cockburn.

485

Варианты Использования (Use Case) / Re: Варианты использования для средств графического проектирования

« : 06 Июня 2008, 13:33:01 »

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

486

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 05 Июня 2008, 14:17:10 »

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

487

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 02 Июня 2008, 22:21:27 »

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

488

Конференции Семинары и Тренинги / Re: [Отчет] о семинаре «Как заставить регламенты работать и приносить пользу»

« : 30 Мая 2008, 12:18:01 »

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

489

Бизнес-анализ и Целеполагание / Re: [Подтема] Средства автоматизации для разработки регламентов

« : 30 Мая 2008, 12:10:52 »

Прямо опошлил :-) ... просто я ковырялся по этой теме еще в Борланд, думая про пришлепки к CaliberRM ...

490

Бизнес-анализ и Целеполагание / Re: [Подтема] Средства автоматизации для разработки регламентов

« : 30 Мая 2008, 11:45:27 »

Тема про единый источник стара. И AuthorIT как тула может для этого быть использована, и DocBook. Но есть вопрос -- почему тот же ДокБук не получил большого распространения, думаю что как раз из-за гемора с преобразованиями XML через xslt. Не всякий аналитик знает досконально xslt. Да и вносить изменения руками в скрипты по каждому чиху довольно трудоемкая задача. Да и в ARIS делать скрипты тоже задча довольно трудоемкая. Вобщем не дешевое это удовольствие, даже на бесплатных тулах.

491

Конференции Семинары и Тренинги / Re: [Отчет] о семинаре «Как заставить регламенты работать и приносить пользу»

« : 30 Мая 2008, 11:33:52 »

Жаль не получилось ... аккурат с 18-00 до 20-00 была встреча. Презентацию в студию!

492

Проектирование / Re: Использование UML при проектировании задач в 1С

« : 27 Мая 2008, 11:51:10 »

Диаграмма активности--"предоставление услуг абоненту"

Я не совсем понял, зачем в диаграмме используются распаралелливание перед шагом 3 (толстая горизонтальная черта) Где там распараллеливание вообще? И какие параллельные активности синхронизируются перед End ?

493

Проектирование / Re: Использование UML при проектировании задач в 1С

« : 26 Мая 2008, 13:40:53 »

Коль скоро это диплом, и тема -- интеграция, то не факт, что я стал бы рисовать UC. Для начала нужно описать процессы в рамках которых происходит интеграция, именно процесс, т.е. описать динамику. Для этого можно использовать хоть тот же BPMN ... отсюда выходим на регламент взаимодействия двух систем. В качестве средства интеграции можно взять не файлы а какой-нить MOM ... и потом в дипломе привести интеграционный сценарий в BEPL, поддерживаемый данным MOM.
 

494

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

« : 20 Мая 2008, 12:18:41 »

В данном случае речь идет о том, что прежде чем изменить требование (непосредственно в документе или в репозитории, в данном случае не столь важно) - нужно внести некое предложение по изменению и пройти формальный approvement (с анализом конечно) по каждому изменению. Тогда становиться очевидным, КАКИЕ пункты документа (или items в репозитории) должны измениться. После утверждения - это изменение вносится. Предусловия -- требования должны быть recognisable, т.е. должны быть построены по определенным правилам (например иерархия + правила формулировка) и иметь свой ID. Тогда процесс внесения изменений упрощается в разы, особенно если сравнивать с ситуацией, когда приходит слабоструктурированный текст ТЗ в документе, где идентифицируются только разделы.
Как вариант по идентифицируемости требований -- старый добрый способ нумеровать подпункты для каждого отдельного statement в ТЗ, при этом подходе уже можно к чему-то адресоваться при изменениях. И для больших контор с советским прошлым такой формат написания ТЗ протащить легче ибо он часто использовался при написании ТЗ.

495

Управление Проектом / Re: Пятый ежегодный форум Oracle для компаний-разработчиков из стран СНГ

« : 20 Мая 2008, 10:28:36 »

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