Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: Constantine1911 от 11 Февраля 2017, 06:23:32
-
Поделитесь стандартным путем достижения до сценариев использования, я понимаю что для каждого программного решения свои дороги. Чтобы хоть от чего нибудь отталкиваться. А то два месяца потратил на прочтение книг, а ясной картины до сих пор не могу увидеть.
Для примера можно взять ИС отдел кадров.
-
Поделитесь стандартным путем достижения до сценариев использования, я понимаю что для каждого программного решения свои дороги. Чтобы хоть от чего нибудь отталкиваться. А то два месяца потратил на прочтение книг, а ясной картины до сих пор не могу увидеть.
Для примера можно взять ИС отдел кадров.
Сходить на тренинг.
Один день вместо двух месяцев. На выходе очень хороший результат.
Впрочем, если у вас времени вагон, то тренинг не ваш метод.
-
Поделитесь стандартным путем достижения до сценариев использования, я понимаю что для каждого программного решения свои дороги. Чтобы хоть от чего нибудь отталкиваться. А то два месяца потратил на прочтение книг, а ясной картины до сих пор не могу увидеть.
Для примера можно взять ИС отдел кадров.
Предложение Сергея вполне разумно. Ясно, что оно стоит денег, но если чтение книг в течение 2 месяцев не принесло результата, возможно, Вам нужен учитель.
Кстати, а какие книги Вы читали? Кстати по отделу кадров вполне неплохо (правда не полно) написано здесь: http://book.uml3.ru
-
Кстати. Главное не уметь писать, а уметь верифицировать требования. А вот это, насколько я знаю, нет нигде, кроме как на моем тренинге. Я думаю как тестировщик и верификация для меня всегда стояла на первом месте. Но из-за отсутствия литературы мне понадобилось очень много лет, чтобы научиться. Коберн верификации уделяет непозволительно мало внимания. А у остальных этого, насколько я знаю, просто ничего нет.
За много лет конференций мне известны три доклада по верификации. Теперь появился четвертый: http://analystdays.ru/ru/talk/45151
-
Предложение Сергея вполне разумно. Ясно, что оно стоит денег, но если чтение книг в течение 2 месяцев не принесло результата, возможно, Вам нужен учитель.
Кстати, а какие книги Вы читали? Кстати по отделу кадров вполне неплохо (правда не полно) написано здесь: http://book.uml3.ru
Я с вами полностью согласен, что если изучение не приносит результата, то нужен человек, который сможет помочь разобраться в изучаемом материале.
Список прочитанных мною книг:
- Дж. Рамбо и М. Блаха - UML2.0 Объектно - ориентированное моделирование и проектирование
- Карл Вигерс и Джой Битти - Разработка требований к программному обеспечению
- Эрик Эванс - Предметно - ориентированное проектирование
- С.А. Орлов и Б.Я. Цилькер - Технологии разработки программного обеспечения
- Алистер Коберн - Современные методы описания функциональных требований к системам
Все книги хорошие, но за одним исключением, они ориентируется на большие проекты, которые делают копании, с не малочисленным персоналом.
Чтобы не разводить холевар, я понял из прочитанных мною книг, самые важные этапы Анализа требований:
- Модель объектов, которая строиться на диаграмме классов
- Древо функций
- Составление сценариев использования
- Составление концептуальной модели проекта
- Делим проект на итерации
Буду рад, волне аргументированной критике.
-
По моему личному мнению, модель объектов как-то рановато затесалась.
Вы еще не определили функции системы, а уже знаете какие объекты вам потребуются.
И мне кажется, что начинать надо с концепции системы - что это такое, зачем она нужна и что она будет уметь делать и чего не будет.
Затем основные(высокоуровневые функции)
Ну а дальше либо пользовательские истории либо варианты использования с дальнейшим их описанием.
Но это мое ИМХО.
-
Буду рад, волне аргументированной критике.
В книге Дж. Рамбо и М. Блаха - UML2.0 Объектно - ориентированное моделирование и проектирование достаточно точно и ясно описан процесс проектирования по мнению авторов.
Все начинается с концептуализации, понимания целей и бизнес-требований. Предположим этот этап пройден и понятен, но в начале все равно нужно получить список функциональны требования и список нефункциональных (показатели качества, требования к данными, ограничения, правила).
ФТ хорошо получать из описания бизнес-процесса (бизнес-процессов), одни или несколько шагов БП могут стать вариантом использования.
С другой стороны можно пойти от модели объектов-предметной области, на самом деле это переплетающиеся шаги. Главное, что нужно начать с того, что понятнее и быстрее позволяет двигаться к цели.
А так есть два подхода -
подход сверху вниз, от цели к ее декомпозиции на функции
подход снизу вверх, от элементарных частей к цели.
В реальности мы используем одновременно оба подхода. НО если вы используете объектно-ориентированный подход, то в большей части идете по второму подходы, т.е. описываете систему как некоторую совокупность взаимодействующих объектов, которые выполняют требуемые функции и проявляют требуемое качество
Ориентация на use cases тоже по сути подход снизу вверх, в котором определяются действующие лица (т.е. окружение системы) и определяются сценарии использования ими системы.
Отдел кадров: сначала понять кто будет взаимодействовать с ИС Отдел кадров - какие люди, какие организации, какие системы. В принципе это просто контекстная диаграмма аля DFD например.
Далее для каждого такого действующего лица определяем эти сценарии использования (т.е. задачи). В результате получим кусочки функциональности, которыми должна обладать ИС ОТдел кадров:
Сотрудник ОК: Прием на работу, Перевод на другую позицию, Увольнение сотрудника, Оформить больничный, Вести кадровые данные и т.п.
и т.п.
Кроме того, диаграмма классов позволяет понять, все ли сценарии учтены, ведь по сути для каждой сущности нужно предусмотреть ввод, изменение, удаление - как минимум, поиск....