Автор Тема: Как добраться до составления сценариев использования?  (Прочитано 788 раз)

Constantine1911

  • Newbie
  • *
  • Сообщений: 2
  • Рейтинг читателей: 0
  • Волков Константин
    • Просмотр профиля
Поделитесь стандартным путем достижения до сценариев использования, я понимаю что для каждого программного решения свои дороги. Чтобы хоть от чего нибудь отталкиваться. А то два месяца потратил на прочтение книг, а ясной картины до сих пор не могу увидеть.
Для примера можно взять ИС отдел кадров.


SALar

  • Member of CAR
  • Sr. Member
  • *****
  • Сообщений: 487
  • Рейтинг читателей: 32
    • Просмотр профиля
    • 255 ступеней
Поделитесь стандартным путем достижения до сценариев использования, я понимаю что для каждого программного решения свои дороги. Чтобы хоть от чего нибудь отталкиваться. А то два месяца потратил на прочтение книг, а ясной картины до сих пор не могу увидеть.
Для примера можно взять ИС отдел кадров.
Сходить на тренинг.
Один день вместо двух месяцев. На выходе очень хороший результат.
Впрочем, если у вас времени вагон, то тренинг не ваш метод.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/

Galogen

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 6060
  • Рейтинг читателей: 192
  • Аксакал
    • Просмотр профиля
    • Профиль в Моем Круге
Поделитесь стандартным путем достижения до сценариев использования, я понимаю что для каждого программного решения свои дороги. Чтобы хоть от чего нибудь отталкиваться. А то два месяца потратил на прочтение книг, а ясной картины до сих пор не могу увидеть.
Для примера можно взять ИС отдел кадров.

Предложение Сергея вполне разумно. Ясно, что оно стоит денег, но если чтение книг в течение 2 месяцев не принесло результата, возможно, Вам нужен учитель.

Кстати, а какие книги Вы читали? Кстати по отделу кадров вполне неплохо (правда не полно) написано здесь: http://book.uml3.ru

SALar

  • Member of CAR
  • Sr. Member
  • *****
  • Сообщений: 487
  • Рейтинг читателей: 32
    • Просмотр профиля
    • 255 ступеней
Кстати. Главное не уметь писать, а уметь верифицировать требования. А вот это, насколько я знаю, нет нигде, кроме как на моем тренинге. Я думаю как тестировщик и верификация для меня всегда стояла на первом месте. Но из-за отсутствия литературы мне понадобилось очень много лет, чтобы научиться. Коберн верификации уделяет непозволительно мало внимания. А у остальных этого, насколько я знаю, просто ничего нет.

За много лет конференций мне известны три доклада по верификации. Теперь появился четвертый: http://analystdays.ru/ru/talk/45151
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/

Constantine1911

  • Newbie
  • *
  • Сообщений: 2
  • Рейтинг читателей: 0
  • Волков Константин
    • Просмотр профиля
Предложение Сергея вполне разумно. Ясно, что оно стоит денег, но если чтение книг в течение 2 месяцев не принесло результата, возможно, Вам нужен учитель.

Кстати, а какие книги Вы читали? Кстати по отделу кадров вполне неплохо (правда не полно) написано здесь: http://book.uml3.ru

Я с вами полностью согласен, что если изучение не приносит результата, то нужен человек, который сможет помочь разобраться в изучаемом материале.
Список прочитанных мною книг:
  • Дж. Рамбо и М. Блаха - UML2.0 Объектно - ориентированное моделирование и проектирование
  • Карл Вигерс и Джой Битти - Разработка требований к программному обеспечению
  • Эрик Эванс - Предметно - ориентированное проектирование
  • С.А. Орлов и Б.Я. Цилькер - Технологии разработки программного обеспечения
  • Алистер Коберн - Современные методы описания функциональных требований к системам
Все книги хорошие, но за одним исключением, они ориентируется на большие проекты, которые делают копании, с не малочисленным персоналом.
Чтобы не разводить холевар, я понял из прочитанных мною книг, самые важные этапы Анализа требований:
  • Модель объектов, которая строиться на диаграмме классов
  • Древо функций
  • Составление сценариев использования
  • Составление концептуальной модели проекта
  • Делим проект на итерации
Буду рад, волне аргументированной критике.

akaCarton

  • Newbie
  • *
  • Сообщений: 20
  • Рейтинг читателей: 2
    • Просмотр профиля
По моему личному мнению, модель объектов как-то рановато затесалась.
Вы еще не определили функции системы, а уже знаете какие объекты вам потребуются.

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

Но это мое ИМХО.

Galogen

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 6060
  • Рейтинг читателей: 192
  • Аксакал
    • Просмотр профиля
    • Профиль в Моем Круге
Буду рад, волне аргументированной критике.

В книге Дж. Рамбо и М. Блаха - UML2.0 Объектно - ориентированное моделирование и проектирование достаточно точно и ясно описан процесс проектирования по мнению авторов.

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

ФТ хорошо получать из описания бизнес-процесса (бизнес-процессов), одни или несколько шагов БП могут стать вариантом использования.

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

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

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

Ориентация на use cases тоже по сути подход снизу вверх, в котором определяются действующие лица (т.е. окружение системы) и определяются сценарии использования ими системы.

Отдел кадров:  сначала понять кто будет взаимодействовать с ИС Отдел кадров - какие люди, какие организации, какие системы. В принципе это просто контекстная диаграмма аля DFD например.

Далее для каждого такого действующего лица определяем эти сценарии использования (т.е. задачи). В результате получим кусочки функциональности, которыми должна обладать ИС ОТдел кадров:

Сотрудник ОК: Прием на работу, Перевод на другую позицию, Увольнение сотрудника, Оформить больничный, Вести кадровые данные и т.п.
и т.п.
Кроме того, диаграмма классов позволяет понять, все ли сценарии учтены, ведь по сути для каждой сущности нужно предусмотреть ввод, изменение, удаление - как минимум, поиск....