Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
. Уже качаю..... Решено- напечатаю фотки на новых визиткахСаша, а как эти визитки будут выглядеть, решили?
.
)Не понял ответа на 2 вопрос. Можно пояснить?Ну во-первых, мне совсем понятно что такое документооборот требований. Во-вторых, документирование требований (шаблоны документов) всегда зависят от заказчика или процесса работы с требованиями. Если есть желание узнать про то как требования по классификации К. Вигерса ложаться на спеки можно посмотреть его книжки, в презентации Алексей тоже попытался это показать. В РУПе та же ситуация. Спецификация, которая готовится для заказчика не создается отдельно от внутреннего процесса разработки - это часть процесса. Если процесс водопадный, то можно сделать спеку, подписать ее у заказчика, а дальше детализировать, создавать постановки задач и тп. Я же считаю что детализация требований, это их анализ и уточнение. Существует много способов анализа требований, и эта тема не относится к классификации (или по крайней мере они не жестко связаны).
Я наверное имел в виду следующую ситуацию. Требования в строгой форме не ведутся, существуют в виде не очень ясных постановок, технологических инструкций, реализаций (т.е. живая система) и в голове у аналитиков и внедренцев, которые работают напрямую с клиентами. Так вот большая проблема этим самые требования получить и положить в тестовые случаяЭдуард, мне кажется ты опять пытаешься решить свою проблему
. Давай вынесем это в отдельную ветку и там поговорим. Не возможно на общем семинаре ответить на проблему, которая не была ранее озвучена, да и без твоего участия я думаю это сложновато. 2. Почему требуется семинар по классификации требований, если в мире существуют уже устойчивые классификации, а при этом в некоторых организация особо не паряться по поводу классификации требований. Требование есть требования.В некоторых организациях не сильно парятся и о сроках реализации продукта и о его качестве. И много еще чего не делают... По-моему намного легче прийти к какому-то решению пообщавшись с живыми людьми, а не книгами. Тем более, что у многих людей просто нет времени читать книги и искать материалы.
Думаю этот вопрос выходит за рамки классификации требований и относится к процессу разработки и документирования требований, а также к их анализу и проектированию системы
3. Как докментируются требования в реальной практике, не как документ для заказчика, тут все ясно, а как документ внутреннего использования. Как вообще организовать документирование и документооборот требований?
4. Как рекомендуется структурировать требования, стоит ли их структурировать? Каковы критерии качественного структурирования требованийПостараемся ответить
5. как выявлятьь требования на тестировние, особенно если они отсутствуют в документальной форме или форма их представления далека от классических норм?Эдуард сформулируй четко, что хочется? Ответить скорее всего уже не успеем но разберем если надо позднее.
Абрамова Анна СергеевнаЕсли вы вдруг передумали, то лучше тоже об этом сообщить, т.к. желающих много а количество мест ограничено
Амиров Тимур Мансурович
Атрощенков Сергей Геннадьевич
Багаев Георгий Владимирович
Баландин Евгений
Бенкевич Владимир Викторович
Глазов Георгий
Дегтярев Анатолий
Долговязов Дмитрий Александрович
Евнуков Евгений Борисович
Егоров Петр
Ефимова Анна Сергеевна
Железко Андрей
Злобин Алексей Николаевич
Зубарев Павел
Зыкова Александра
Калиничев Александр Олегович
Карпов Иван Георгиевич
Катков Юрий
Кирьянов Олег Александрович
Коваленко Ольга Владимировна
Любимов Борис Михайлович
Мальцева Анна Викторовна
Никулин Алексей
Орешков Андрей
Панферов Антон
Петров Юрий
Руденко Александра Андреевна
Смирнова Татьяна Александровна
Сотавов Абакар Капланович
Сурова Ирина Николаевна
Щекалов Антон
.. а пакет -- это классификатор, как мне кажется.А по-моему пакет не относится к классификаторам. Хотя могу ошибаться
Энто как ты будешь использовать Компоненты также?При моделировании ВИ в IBM Rational Software Architect граница системы представляет собой компонент со стереотипом <<subsystem>>, а не просто картинка в виде рамочки. Такой подход позволяет помещать ВИ внутрь действительной системы. Декомпозируя систему на подсистемы (компоненты), мы тем самым группируем ВИ по подсистемам. См. рисунок1 в аттаче. Так как по правилам UML актор может быть связан с компонентом, то мы можем на верхнем уровне абстракции показать эту связь, скрыв внутреннее содержание компонента. Связи акторов с компонентами, на этапе проектирования перерастут в интерфейсы.
1. Я не против такого использования, но просто как правило ДЛ не участвует во всех ВИ данного пакета, а, во-вторых, ДВИ с Пакетами и ДЛ может получиться нечитаемой, т.к. одно или несколько ДЛ будет связано со всеми Пакетами, и поэтому данный вид Д нужно использовать осторожно (не все еще ДВИ одолели то).Чтобы не было таких проблем нужно придерживаться принципа проектирования: элементы внутри компонента сильно связаны, компоненты слабо зависимы. Это позволит сократить количество взаимодействий между компонентами и сделать более гибкую архитектуру. Конечно, это все больше относится к системным вариантам использования.
2. ПоверимДоверяй, но проверяй
. См. рисунок 2 в аттаче3. Так ЕА позволяет делать все что угодноДа, это ИМХО., и я его никому не навязываю и не утверждаю что это правильно
З.Ы. Это твое ИМХО, хотя логичное. М.б. написать в ОМГ на счет включения Пакетов на ДВИ или спросить причину того что они этого не сделали?
. А в ОМГ написать можно. Займешься?
...Это кстати на заметку Виталию Григорашу, кот показывал патерн ВИ "Пакеты", где было отношение зависимости м\у ДЛ и Пакетами.Хочу немного своего мнения внести.
Где там??Я имел ввиду фильтры в Матрице.
