|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
29 марта, в 7 часов вечера UML2.ru при поддержке компании Luxoft проводит семинар на тему "Разработка требований и состава работ - Холистический подход" Многие начинающие, и не только, аналитики и менеджеры становятся в тупик при попытках описать требования и спланировать работу по созданию системы, в лучшем случае опираясь лишь на примеры работ по другим проектам. Традиционные и достаточно современные подходы к определению требований к системе и состава работ, изложенные в BABOK, PMBOK, SWEBOK и специализированной литературе (Вигерс, Коберн, Лефингвел), несмотря не свои очевидные достижения, не предлагают метода формирования целостного и взаимоувязанного представления о создаваемой системе, и следовательно, требований к её внешним и внутренним свойствам, а также работ, необходимых для её создания, и, что исключительно важно, эффективной эксплуатации. На семинаре будет предложен к рассмотрению и обсуждению простой и наглядный подход к формированию видения системы, основанный на едином сценарии использования системы с элементами деревьев решений, ментальных карт, и каузальных диаграмм. Будут описаны особенности применения данного метода, даны рекомендации по использованию инструментов, приведены практические примеры. Чтобы попасть на семинар, пришлите свои ФИО на rq_workshop (o) beskov.ru Адрес проведения семинара: метро Октябрьское Поле, 1-й волоколамский проезд, д.10 строение 3 Путь от метро: первый вагон из центра, выход по подземному переходу направо, потом сразу налево, далее проходите около 50 метров вперед на остановку 105 и 800. Вам необходимы автобусы NN 105, 800, следующие до остановки "1-й Волоколамские проезд". Автобус останавливается напротив первой проходной. Либо пешком от метро, идти минут 10. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2007, 11:28 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
IMHO начинать надо с международного стандарта: Стандарт ISO 9126 [1-4] предлагает использовать для описания внутреннего и внешнего качества ПО многоуровневую модель. На верхнем уровне выделено 6 основных характеристик качества ПО . Каждая характеристика описывается при помощи нескольких входящих в нее атрибутов. Для каждого атрибута определяется набор метрик, позволяющих оценить этот атрибут. Набор характеристик и атрибутов качества согласно ISO 9126 показан ================= Функциональность (functionality). Способность ПО в определенных условиях решать задачи, нужные пользователям. Определяет, что именно делает ПО, какие задачи оно решает. o Функциональная пригодность (suitability). Способность решать нужный набор задач. o Точность (accuracy). Способность выдавать нужные результаты. o Способность к взаимодействию (interoperability). Способность взаимодействовать с нужным набором других систем. o Соответствие стандартам и правилам (compliance). Соответствие ПО имеющимся индустриальным стандартам, нормативным и законодательным актам, другим регулирующим нормам. o Защищенность (security). Способность предотвращать неавторизированный, т.е. без указания лица, пытающегося его осуществить, и не разрешенный доступ к данным и программам. Надежность (reliability). Способность ПО поддерживать определенную работоспособность в заданных условиях. o Зрелость, завершенность (maturity). Величина, обратная к частоте отказов ПО. o Устойчивость к отказам (fault tolerance) Способность поддерживать заданный уровень работоспособности при отказах и нарушениях правил взаимодействия с окружением. o Способность к восстановлению (recoverability). Способность восстанавливать определенный уровень работоспособности и целостность данных после отказа, необходимые для этого время и ресурсы. o Соответствие стандартам надежности (reliability compliance). Этот атрибут добавлен в 2001 году. • Удобство использования (usability) или практичность. Способность ПО быть удобным в обучении и использовании, а также привлекательным для пользователей. o Понятность (understandability). Показатель, обратный к усилиям, затрачиваемым пользователями, чтобы воспринять набор понятий, на которых основано ПО, и их применимость для решения своих задач. o Удобство обучения (learnability). Показатель, обратный к усилиям, затрачиваемым пользователями чтобы научиться работе с ПО. o Удобство работы (operability). Показатель, обратный к усилиям, предпринимаемым пользователями, чтобы решать свои задачи с помощью ПО. o Привлекательность (attractiveness). Способность ПО быть привлекательным для пользователей. Этот атрибут добавлен в 2001. o Соответствие стандартам удобства использования (usability compliance). Этот атрибут добавлен в 2001. Производительность (efficiency) или эффективность. Способность ПО при заданных условиях обеспечивать необходимую работоспособность по отношению к выделяемым для этого ресурсам. Можно определить ее и как отношение получаемых с помощью ПО результатов к затрачиваемым на это ресурсам. o Временная эффективность (time behaviour). Способность ПО выдавать ожидаемые результаты, а также обеспечивать передачу необходимого объема данных за отведенное время. o Эффективность использования ресурсов (resource utilisation). Способность решать нужные задачи с использованием определенных объемов ресурсов определенных видов. Имеются в виду такие ресурсы, как оперативная и долговременная память, сетевые соединения, устройства ввода и вывода, и пр. o Соответствие стандартам производительности (efficiency compliance). Этот атрибут добавлен в 2001. • Удобство сопровождения (maintainability). Удобство проведения всех видов деятельности, связанных с сопровождение программ. o Анализируемость (analyzability) или удобство проведения анализа. Удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа на предмет необходимых изменений и их возможных эффектов. o Удобство внесения изменений (changeability). Показатель, обратный к трудозатратам на проведение необходимых изменений. o Стабильность (stability). Показатель, обратный к риску возникновения неожиданных эффектов при внесении необходимых изменений. o Удобство проверки (testability). Показатель, обратный к трудозатратам на проведение тестирования и других видов проверки того, что внесенные изменения привели к нужным эффектам. o Соответствие стандартам удобства сопровождения (maintainability compliance). Этот атрибут добавлен в 2001. • Переносимость (portability). Способность ПО сохранять работоспособность при переносе из одного окружения в другое, включая организационные, аппаратные и программные аспекты окружения. Иногда эта характеристика называется в русскоязычной литературе мобильностью. Однако термин «мобильность» стоит зарезервировать для перевода «mobility» — способности ПО и компьютерной системы в целом сохранять работоспособность при ее физическом перемещении в пространстве. o Адаптируемость (adaptability). Способность ПО приспосабливаться к различным окружениям без проведения для этого действий, помимо заранее предусмотренных. o Удобство установки (installability). Способность ПО быть установленным или развернутым в определенном окружении. o Способность к сосуществованию (coexistence). Способность ПО сосуществовать с другими программами в общем окружении, деля с ним ресурсы. o Удобство замены (replaceability) другого ПО данным. Способность ПО использоваться вместо другого ПО для решения тех же самых задач в заданном окружении. o Соответствие стандартам переносимости (portability compliance). Этот атрибут добавлен в 2001 ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2007, 14:20 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
Petro, посмотрите диаграмму взаимосвязей типов требований у Вигерса, там ясно видно, что атрибуты качества, о которых говорит 9126 - это важная, но не основная составляющая требований, на фоне бизнес-требований, пользовательских требований, системных требований, функциональных требований, бизнес-правил, внешних интерфейсов и ограничений. Кстати, полезнее было бы дать ссылку на раздел учебного курса, где этот стандарт обсуждается: http://www.intuit.ru/department/se/compprog/5/2.html ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2007, 00:37 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
Майевтик Petro, посмотрите диаграмму взаимосвязей типов требований у Вигерса, там ясно видно, что атрибуты качества, о которых говорит 9126 - это важная, но не основная составляющая требований ======== ссылки нет? Т.к. непонятно как может быть "ГОСТ" не важной частью. А научно-популярная литература..., на то она и литература. Вон сейчас и Дарвин стал не в моде в школах :). Кстати, полезнее было бы дать ссылку на раздел учебного курса, где этот стандарт обсуждается: http://www.intuit.ru/department/se/compprog/5/2.html ===== не видно обсуждения, т.к. лекция. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2007, 11:00 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2007, 11:20 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
МайевтикPetro, пожалуйста, читайте буквально, что я пишу. Поиск в гугле "виды требований вигерс" за ссылку спасибо. IMHO Вигерс разработал методологию работы с требованиями (систематизацию и классификацию), а сами требования отображены в стандартах (иначе нет язака разговора с заказчиком). ЗЫ. "ментальные карты" вероятно интересное решение при работе с визуализацией требований. Удачи! ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2007, 11:48 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
Выложены материалы семинара . ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2007, 02:05 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
МайевтикВыложены материалы семинара . интересен пример применения "ментальных карт", но ...... немного покритикую и добавлю к bas : - bas Плюсы и область применения: Маленький (возможно средний) проект с небольшим кол-вом требований и аналитиков Хорошая наглядность (видна не противоречивость) и лекго/быстро можно набросать несколько 10ов требований Если есть куча муккулатуры, называемая ТЗ, то можно лекго вычленить требования и их структурировать Небольшая стоимость продукта (MindMap) Легкий импорт/экспорт в Excel/Word/Project Больщое кол-во разных доп. иконок, связей и т.д. Минусы и область слабого применения: Не возможно управлять большим кол-вом требований Не поддерживается версионность Не возможно править одновременно несколькими участниками Не возможность синхронизирования с Excel/Word/Project, т.е. экспортнули в Проджект там что-то попроавили и обратно Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования Дополняйте .... - архив-ссылка - битый - данный метод "негостированный" и поэтому всё-таки требует обзора "классических методов" (согласен с Юрий Булуй ) - некоторая мешанина из целей к проге, возможностей проги, этапов проектирования и разработки, требований к программному продукту. - некоторая необязательность (художественность) схемы для работы с заказчиком (нет количественных величин и связей с ГОСТом выше). Т.е. для менеджера может подойти, но для тех-специалиста неконкретна. IMHO ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2007, 11:20 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
Пример целевого сценария и дерева требований и работ для типовой Справочной корпоративной информационной системы. ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2007, 11:21 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2007, 11:22 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
Petro123 МайевтикВыложены материалы семинара . интересен пример применения "ментальных карт", но ...... немного покритикую и добавлю к bas : - bas Плюсы и область применения: Маленький (возможно средний) проект с небольшим кол-вом требований и аналитиков Хорошая наглядность (видна не противоречивость) и лекго/быстро можно набросать несколько 10ов требований Если есть куча муккулатуры, называемая ТЗ, то можно лекго вычленить требования и их структурировать Небольшая стоимость продукта (MindMap) Легкий импорт/экспорт в Excel/Word/Project Больщое кол-во разных доп. иконок, связей и т.д. Минусы и область слабого применения: Не возможно управлять большим кол-вом требований Не поддерживается версионность Не возможно править одновременно несколькими участниками Не возможность синхронизирования с Excel/Word/Project, т.е. экспортнули в Проджект там что-то попроавили и обратно Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования Дополняйте .... - архив-ссылка - битый - данный метод "негостированный" и поэтому всё-таки требует обзора "классических методов" (согласен с Юрий Булуй ) - некоторая мешанина из целей к проге, возможностей проги, этапов проектирования и разработки, требований к программному продукту. - некоторая необязательность (художественность) схемы для работы с заказчиком (нет количественных величин и связей с ГОСТом выше). Т.е. для менеджера может подойти, но для тех-специалиста неконкретна. IMHO Petro, приходи общаться на www.UML2.ru , и если не сложно, то запость туда свой ответ, я думаю Денису найдется, что ответить :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2007, 12:20 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
bas Спасибо за приглашение. Редко, но бывал у Вас. "Запостить" можете Вы, сделав копию. Я не могу по многим причинам: - совершенно нет времени (поэтому и на семинары не хожу); - кросспостинг приносит пользу в редких случаях (каюсь, грешил :)); - чем публичнее обсуждение, тем пользы больше (как там это называется в аналитике? Мозговой штурм? :)) ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2007, 13:19 |
|
МСК - Семинар "Разработка требований и состава работ"
|
|||
---|---|---|---|
#18+
Petro123- чем публичнее обсуждение, тем пользы больше (как там это называется в аналитике? Мозговой штурм? :)) Публичноеть не обязательно подразуемевает качество обсуждения ... главное чтобы обсуждение не перерастало во флейм. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.04.2007, 15:45 |
|
|
start [/forum/topic.php?fid=33&msg=34415016&tid=1549116]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
45ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 41ms |
total: | 176ms |
0 / 0 |