Аналитик и SDLC (Software Development Lifecycle)




Главная   Форумы   Общие вопросы и обсуждения   Аналитик и SDLC (Software Development Lifecycle)

В теме 1 ответ, и 2 участника, последнее обновление сделано пользователем Аватар (Gerych) Герман Шестеров 14 г, 10 мес. назад.

Показано 2 ответа - от 1 до 2 (всего 2)
  • Автор
    Сообщения
  • 12.02.2010 в 22:40 # 4275
    Я вот считаю, что аналитик имеет прямое отношение к SDLC (процессам разработки ПО). Более того, я лично считаю, что именно аналитики должны заниматься выработкой подходящего / адаптацией существующих, внедрением и поддержанием (всё это по согласованию с ПМом, конечно) SDLC на проекте. Ну это личное мнение, но дело не в этом.

    А вопросы такие: по каким SDLC вы работали / работаете? Какие вам понравились, какие нет? и почему?

    Поделиться:

    Цитировать

    14.02.2010 в 00:20 # 4276
    Юрий, я так понял, вы имеете в виду методологии разработки ПО, то бишь водопадная, scrum и т.п.? Я ни в коем случае не доколебываюсь к терминам, просто хотел уточнить :) , потому что в плане именно видов SDLC я ничего не знаю и может сейчас пойду рассуждать в неверном направлении :oops: .
    Да, я абсолютно согласен, что аналитик имеет прямое отношение к SDLC и в целом — аналитик, как в принципе и любой другой участник разработки, должен знать и понимать процесс разработки, его виды и их особенности.
    Я работал на проектах, организованных по таким методологиям:
    1) Waterfall ("водопадка", tollgate). Процесс, на мой взгляд, устаревший и неактуальный в наши суровые времена выживания и конкуренции. Удобен и интуитивно понятен своей простотой, но весьма неэффективен. Пытались по нему работать (по инициативе самого заказчика), но вскоре отказались (опять же по инициативе заказчика). Кастомер поигрался и понял, что получая организованность и прозрачность, он жертвует скоростью и гибкостью.
    2) Спиральная модель. В принципе — этой мой выбор процесса разработки. Нечто среднее, как мне кажется, между водопадом и agile. Средняя степень гибкости + значительная степень организованности и контролируемости. Мы работали с заказчиком по такой системе долгое время, пока не наступила необходимость "делать быстрее".
    3) Agile Development. Мне лично не нравится, потому что у нас agile понимают немного по-своему, а именно: делай быстро и качественно, но при этом достаточно ресурсов на проект не дадим, так как на дворе сложная экономическая ситуация… Если говорить для меня как аналитика, то это вообще катастрофа — я люблю ответственно подходить к работе, и если уж разрабатывать требования к системе, то делать это качественно. А здесь приходится долго думать над средним между временем и достаточностью. В итоге требованиями получаются неполными и некачественными. Остается только слезами обливаться и тосковать по "характеристикам превосходных требований" Вигерса :)
    Есть, конечно, и другие методологии процесса разработки, но во-первых на мой взгляд границы между ними немного размыты, а во-вторых мало кто официально объявляет, что вот этот проект "будем делать так", поэтому приходится самому анализировать ситуацию и пытаться понять, а под какой же процесс подходит то, как мы сейчас работаем. Ну ведь на то мы и аналитики, ведь так? :)
    Поделиться:

    Цитировать

Показано 2 ответа - от 1 до 2 (всего 2)

Вы должны авторизироваться для ответа в этой теме.