SlideShare a Scribd company logo
Лекция 6. Особенности работы системного аналитика
ПРОМЫШЛЕННАЯ РАЗРАБОТКА ПО
• Кто такие системные
аналитики?
• Цели и задачи аналитика в
проекте
• Особенности первичного
анализа системы
• Участие аналитика в процессе
разработки
• Качества, необходимые
аналитику
О ЧЁМ БУДЕМ ГОВОРИТЬ СЕГОДНЯ
СИСТЕМНЫЙ АНАЛИТИК - ЭТО
Специалист в области анализа предметной
области и формулирования требований к
разрабатываемым информационным системам
и прикладному программному обеспечению
• Формирование полных,
непротиворечивых и
актуальных требований к
системе
• Соответствие
разрабатываемой системы
ожиданиям пользователя
ЦЕЛИ АНАЛИТИКА
Проф. стандарт «системный аналитик»: http://www.apkit.ru/committees/education/meetings/standarts.php
• Исследование предметной
области системы
• Детальное описание системы и
составление соответствующей
документации
• Формирование требований к
системе
• Поддержание требований в
актуальном состоянии
• Взаимодействие с заказчиком
и командой разработки
ОСНОВНЫЕ ЗАДАЧИ
• Написание проектной
документации
• Декомпозиция задач для
первичной оценки трудозатрат
• Создание макетов
пользовательского интерфейса
ДОПОЛНИТЕЛЬНЫЕ ЗАДАЧИ
Аналитик отвечает за то, ЧТО будет сделано в то время, как команда
разработки за то, КАК это будет сделано
СЛЕДСТВИЕ 1
Успех проекта напрямую зависит от того, насколько хорошо аналитик
проработал требования
СЛЕДСТВИЕ 2
Более половины всех неудач проектов связаны с проблемами в управлении
требованиями: неполные требования, бесконтрольные изменения и т.д.
ФАКТ О ПРОВАЛЕ ПРОЕКТА
SPIN-OFF: ВАРИАНТЫ ОПЛАТЫ ЗАКАЗНОЙ
РАЗРАБОТКИ
• Оплата производится по факту
затраченных часов
• Изменения оплачиваются в
общем потоке
• Обычно оплата производится
периодически
• Стоимость проекта
рассчитывается до его старта
• Каждое отклонение от ТЗ
рассматривается как
изменение и добавляется в
общую стоимость
• Оплата приурочена к
контрольным точкам проекта
ВАРИАНТЫ ОПЛАТЫ ЗАКАЗНОЙ РАЗРАБОТКИ
Fixed Price Time & Material
ПОДРОБНЕЕ О ЗАДАЧАХ
• Общение с
заинтересованными лицами
• Понимание задач, решаемых
пользователями
• Моделирование бизнес-
процессов предметной области
• Исследование решений,
которые используются в
данный момент
ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
• Описание общего списка
функций системы
• Детальное описание каждой
функции
• Уточнение деталей у заказчика
• Описание ограничений и
нефункциональных требований
• Согласование списка функций
с заказчиком или
заинтересованными лицами
ФОРМИРОВАНИЕ ТРЕБОВАНИЙ
• Уточнение неясных деталей
• Выяснение его видения
отдельных функций и системы
в целом
• Выяснение нефункциональных
требований
• Утверждение спецификации
• Трансляция вопросов команды
ВЗАИМОДЕЙСТВИЕ С ЗАКАЗЧИКОМ
• Доведения требований до
каждого разработчика
(постановка задачи)
• Объяснение непонятных
моментов в требованиях
• Решение спорных вопросов
• Консультация тестировщика
ВЗАИМОДЕЙСТВИЕ С КОМАНДОЙ РАЗРАБОТКИ
Аналитик – представитель заказчика в команде разработки
СЛЕДСТВИЕ 3
ПЕРВИЧНЫЙ АНАЛИЗ ПРОЕКТА
• Заказчик предоставляет заявку на
предложение (Request for proposal)
• На основе RFP аналитик формирует
видение системы и задаѐт
уточняющие вопросы
• Заказчик даѐт ответы на вопросы
• Аналитик предоставляет
коммерческое предложение (proposal):
видение проекта и грубую оценку
трудозатрат
• При удовлетворении заказчика
запускается фаза анализа системы
ПРОЦЕСС ПЕРВИЧНОГО АНАЛИЗА ПРИ ЗАКАЗНОЙ
РАЗРАБОТКЕ
• Аналитик детально прорабатывает
требования к системе
• Заказчик предоставляет
дополнительную информацию и
вносит коррективы
• Заказчик утверждает ТЗ
• Аналитик формирует список
функций системы, после чего
производится их финальная оценка
вместе с командой разработки
• Разрабатывается архитектура
системы
Предпродажная фаза
(presale)
Фаза анализа*
В зависимости от методологии разработки содержание фазы анализа может меняться
• RFP иногда содержит всего
пару абзацев
• Подготовка коммерческого
предложения идѐт в очень
сжатые сроки
• Часто работа идѐт в условиях
жѐсткой конкуренции
• Первичная оценка может в
несколько раз отличаться от
финальной (обычно – в
меньшую сторону)
ОСОБЕННОСТИ PRESALE-ФАЗЫ
При работе на аукционных площадках доля выигранных проектов ~3%
• Чем детальнее будет
проработаны требования, тем
меньше проблем возникнет в
ходе разработки проекта
• Самая большая опасность для
проекта – необходимые
требования и функции,
отсутствующие в ТЗ
• Требования обязательно будут
меняться в процессе
разработки. Важно управлять
этими изменениями
ОСОБЕННОСТИ ФАЗЫ АНАЛИЗА
Некоторые методологии не предполагают отдельную фазу анализа
ПОДДЕРЖКА СИСТЕМЫ В ПРОЦЕССЕ
РАЗРАБОТКИ
• Требования для функции
должны быть сформированы
к началу её разработки
• В процессе разработки
требования к системе не раз
претерпят изменения
• Новые требования должны
обрабатываться и добавляться в
систему таким же образом, как
первоначальные
• Требования должны быть
понятными всем участникам
проектной команды
ОСОБЕННОСТИ АНАЛИТИКИ ВО ВРЕМЯ
РАЗРАБОТКИ
ЕЩЁ РАЗ О СТАТИСТИКЕ
• 51% всех провалов проектов случается из-за некачественного управления
изменениями требований
• 48% всех провалов проектов случается из-за неправильной оценки трудозатрат (в
том числе из-за неучтѐнных функций
Роберт Гласс: «Факты и заблуждения профессиоального программирования»
http://www.ozon.ru/context/detail/id/3707281/
• Способность увидеть систему с
точки зрения пользователя
• Дотошность, внимание к
деталям
• Способность увидеть скрытые
функции системы
• Способность разговаривать на
языке как заказчика, так и
разработчиков
• Навыки технического писателя
• В большинстве случаев – знание
английского
ОСНОВНЫЕ НАВЫКИ СИСТЕМНОГО АНАЛИТИКА
ВРЕМЯ ЗАДАВАТЬ ВОПРОСЫ

More Related Content

What's hot

План тестирования
План тестированияПлан тестирования
План тестирования
EDISON Software Development Centre
 
Документирование дефектов
Документирование дефектовДокументирование дефектов
Документирование дефектов
Nickola14
 
QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...
QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...
QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...
QAFest
 
Severity и Priority для неначинающих: очевидное и невероятное
Severity и Priority для неначинающих: очевидное и невероятноеSeverity и Priority для неначинающих: очевидное и невероятное
Severity и Priority для неначинающих: очевидное и невероятное
Deutsche Post
 
Шаблоны оформления требований
Шаблоны оформления требованийШаблоны оформления требований
Шаблоны оформления требований
JaneKozmina
 
Оптимизируем тест кейсы
Оптимизируем тест кейсыОптимизируем тест кейсы
Оптимизируем тест кейсы
SQALab
 
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестированииМетод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
Deutsche Post
 
Automation from the trenches
Automation from the trenchesAutomation from the trenches
Automation from the trenches
Gleb Rybalko
 
Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктах
Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктахШаблоны трассировок бизнес-требований на больших кросс-проектных продуктах
Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктах
SQALab
 
Пять вещей, которые нужно знать заказчику
Пять вещей, которые нужно знать заказчикуПять вещей, которые нужно знать заказчику
Пять вещей, которые нужно знать заказчику
Sergey Lourie
 
Tpo 05111(1)
Tpo 05111(1)Tpo 05111(1)
Tpo 05111(1)
Nickola14
 
Требования по безопасности в архитектуре ПО
Требования по безопасности в архитектуре ПОТребования по безопасности в архитектуре ПО
Требования по безопасности в архитектуре ПО
Positive Hack Days
 
Эволюция автотестирования на Selenium
Эволюция автотестирования на SeleniumЭволюция автотестирования на Selenium
Эволюция автотестирования на Selenium
SQALab
 
Agile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
Agile Java Development компания JazzTeam - Техническая презентация Xml2SeleniumAgile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
Agile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
jazzteam
 
Java one presentation
Java one presentationJava one presentation
Java one presentation
Shamim bhuiyan
 
Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4
Dima Dzuba
 
тестирование снецифических областей
тестирование снецифических областейтестирование снецифических областей
тестирование снецифических областей
DressTester
 
SqaВфны8
SqaВфны8SqaВфны8
SqaВфны8
Catherine Tipanova
 
Методики управления развитием ис на базе 1с
Методики управления развитием ис на базе 1сМетодики управления развитием ис на базе 1с
Методики управления развитием ис на базе 1с
Helen Kopteva
 
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
QAFest
 

What's hot (20)

План тестирования
План тестированияПлан тестирования
План тестирования
 
Документирование дефектов
Документирование дефектовДокументирование дефектов
Документирование дефектов
 
QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...
QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...
QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...
 
Severity и Priority для неначинающих: очевидное и невероятное
Severity и Priority для неначинающих: очевидное и невероятноеSeverity и Priority для неначинающих: очевидное и невероятное
Severity и Priority для неначинающих: очевидное и невероятное
 
Шаблоны оформления требований
Шаблоны оформления требованийШаблоны оформления требований
Шаблоны оформления требований
 
Оптимизируем тест кейсы
Оптимизируем тест кейсыОптимизируем тест кейсы
Оптимизируем тест кейсы
 
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестированииМетод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
 
Automation from the trenches
Automation from the trenchesAutomation from the trenches
Automation from the trenches
 
Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктах
Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктахШаблоны трассировок бизнес-требований на больших кросс-проектных продуктах
Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктах
 
Пять вещей, которые нужно знать заказчику
Пять вещей, которые нужно знать заказчикуПять вещей, которые нужно знать заказчику
Пять вещей, которые нужно знать заказчику
 
Tpo 05111(1)
Tpo 05111(1)Tpo 05111(1)
Tpo 05111(1)
 
Требования по безопасности в архитектуре ПО
Требования по безопасности в архитектуре ПОТребования по безопасности в архитектуре ПО
Требования по безопасности в архитектуре ПО
 
Эволюция автотестирования на Selenium
Эволюция автотестирования на SeleniumЭволюция автотестирования на Selenium
Эволюция автотестирования на Selenium
 
Agile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
Agile Java Development компания JazzTeam - Техническая презентация Xml2SeleniumAgile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
Agile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
 
Java one presentation
Java one presentationJava one presentation
Java one presentation
 
Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4
 
тестирование снецифических областей
тестирование снецифических областейтестирование снецифических областей
тестирование снецифических областей
 
SqaВфны8
SqaВфны8SqaВфны8
SqaВфны8
 
Методики управления развитием ис на базе 1с
Методики управления развитием ис на базе 1сМетодики управления развитием ис на базе 1с
Методики управления развитием ис на базе 1с
 
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
 

Similar to Промышленная разработка ПО. Лекция 6. Особенности работы системного аналитика

Требования к по
Требования к поТребования к по
Требования к по
JaneKozmina
 
DUMP-2013 Управление разработкой - Как дорасти до аналитика? - Желнова Наталья
DUMP-2013 Управление разработкой - Как дорасти до аналитика? - Желнова НатальяDUMP-2013 Управление разработкой - Как дорасти до аналитика? - Желнова Наталья
DUMP-2013 Управление разработкой - Как дорасти до аналитика? - Желнова Наталья
it-people
 
Sep reqm-lec1
Sep reqm-lec1Sep reqm-lec1
Sep reqm-lec1
Natalia Zhelnova
 
ИТ-процессы: бодры, мощны и всегда готовы!
ИТ-процессы: бодры, мощны и всегда готовы!ИТ-процессы: бодры, мощны и всегда готовы!
ИТ-процессы: бодры, мощны и всегда готовы!
КРОК
 
5 alina petrenko - key requirements elicitation during the first contact wi...
5   alina petrenko - key requirements elicitation during the first contact wi...5   alina petrenko - key requirements elicitation during the first contact wi...
5 alina petrenko - key requirements elicitation during the first contact wi...
Ievgenii Katsan
 
Никита Ремизов - Введение в разработку ТЗ
Никита Ремизов - Введение в разработку ТЗНикита Ремизов - Введение в разработку ТЗ
Никита Ремизов - Введение в разработку ТЗ
DrupalSPB
 
Нефункциональные требования
Нефункциональные требованияНефункциональные требования
Нефункциональные требования
Natalia Zhelnova
 
Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?
SQALab
 
IT-шная история игрушек или feature-driven тестирование в действии
IT-шная история игрушек или feature-driven тестирование в действииIT-шная история игрушек или feature-driven тестирование в действии
IT-шная история игрушек или feature-driven тестирование в действии
Gleb Rybalko
 
Завершение проектов
Завершение проектовЗавершение проектов
Завершение проектов
Timofei Tatarinov
 
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUAREТехники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
SQALab
 
Requirements in Agile
Requirements in AgileRequirements in Agile
Requirements in Agile
Natalya Grachyova
 
Оценка эффективности работы аналитика
Оценка эффективности работы аналитикаОценка эффективности работы аналитика
Оценка эффективности работы аналитика
SQALab
 
Analyst Days 2014
Analyst Days 2014Analyst Days 2014
Analyst Days 2014
Natalia Zhelnova
 
практика управления требованиями
практика управления требованиямипрактика управления требованиями
практика управления требованиями
ISsoft
 
Cтадии проекта и состав технической документации
Cтадии проекта и состав технической документацииCтадии проекта и состав технической документации
Cтадии проекта и состав технической документации
Natalia Zhelnova
 
Проектирование_и_архитектура_ПС_2022_L05s.ppt
Проектирование_и_архитектура_ПС_2022_L05s.pptПроектирование_и_архитектура_ПС_2022_L05s.ppt
Проектирование_и_архитектура_ПС_2022_L05s.ppt
dinarium2016
 
Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34
Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34
Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34
Alexandra Varfolomeeva
 

Similar to Промышленная разработка ПО. Лекция 6. Особенности работы системного аналитика (20)

Требования к по
Требования к поТребования к по
Требования к по
 
DUMP-2013 Управление разработкой - Как дорасти до аналитика? - Желнова Наталья
DUMP-2013 Управление разработкой - Как дорасти до аналитика? - Желнова НатальяDUMP-2013 Управление разработкой - Как дорасти до аналитика? - Желнова Наталья
DUMP-2013 Управление разработкой - Как дорасти до аналитика? - Желнова Наталья
 
Dump nzh 01
Dump nzh 01Dump nzh 01
Dump nzh 01
 
MS ALM 2013 Review
MS ALM 2013 ReviewMS ALM 2013 Review
MS ALM 2013 Review
 
Sep reqm-lec1
Sep reqm-lec1Sep reqm-lec1
Sep reqm-lec1
 
ИТ-процессы: бодры, мощны и всегда готовы!
ИТ-процессы: бодры, мощны и всегда готовы!ИТ-процессы: бодры, мощны и всегда готовы!
ИТ-процессы: бодры, мощны и всегда готовы!
 
5 alina petrenko - key requirements elicitation during the first contact wi...
5   alina petrenko - key requirements elicitation during the first contact wi...5   alina petrenko - key requirements elicitation during the first contact wi...
5 alina petrenko - key requirements elicitation during the first contact wi...
 
Никита Ремизов - Введение в разработку ТЗ
Никита Ремизов - Введение в разработку ТЗНикита Ремизов - Введение в разработку ТЗ
Никита Ремизов - Введение в разработку ТЗ
 
Нефункциональные требования
Нефункциональные требованияНефункциональные требования
Нефункциональные требования
 
Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?
 
IT-шная история игрушек или feature-driven тестирование в действии
IT-шная история игрушек или feature-driven тестирование в действииIT-шная история игрушек или feature-driven тестирование в действии
IT-шная история игрушек или feature-driven тестирование в действии
 
Завершение проектов
Завершение проектовЗавершение проектов
Завершение проектов
 
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUAREТехники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
 
Requirements in Agile
Requirements in AgileRequirements in Agile
Requirements in Agile
 
Оценка эффективности работы аналитика
Оценка эффективности работы аналитикаОценка эффективности работы аналитика
Оценка эффективности работы аналитика
 
Analyst Days 2014
Analyst Days 2014Analyst Days 2014
Analyst Days 2014
 
практика управления требованиями
практика управления требованиямипрактика управления требованиями
практика управления требованиями
 
Cтадии проекта и состав технической документации
Cтадии проекта и состав технической документацииCтадии проекта и состав технической документации
Cтадии проекта и состав технической документации
 
Проектирование_и_архитектура_ПС_2022_L05s.ppt
Проектирование_и_архитектура_ПС_2022_L05s.pptПроектирование_и_архитектура_ПС_2022_L05s.ppt
Проектирование_и_архитектура_ПС_2022_L05s.ppt
 
Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34
Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34
Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34
 

More from Mikhail Payson

Промышленная разработка ПО. Лекция 8. Особенности работы руководителя проекто...
Промышленная разработка ПО. Лекция 8. Особенности работы руководителя проекто...Промышленная разработка ПО. Лекция 8. Особенности работы руководителя проекто...
Промышленная разработка ПО. Лекция 8. Особенности работы руководителя проекто...
Mikhail Payson
 
Промышленная разработка ПО. Лекция 7. Особенности работы руководителя проектов
Промышленная разработка ПО. Лекция 7. Особенности работы руководителя проектовПромышленная разработка ПО. Лекция 7. Особенности работы руководителя проектов
Промышленная разработка ПО. Лекция 7. Особенности работы руководителя проектов
Mikhail Payson
 
Пара слов о рисках
Пара слов о рискахПара слов о рисках
Пара слов о рисках
Mikhail Payson
 
Руководитель - это про людей (CIOConf 2013, Барнаул)
Руководитель - это про людей (CIOConf 2013, Барнаул)Руководитель - это про людей (CIOConf 2013, Барнаул)
Руководитель - это про людей (CIOConf 2013, Барнаул)
Mikhail Payson
 
Why you should think twice before giving your programmer to design the UI
Why you should think twice before giving your programmer to design the UIWhy you should think twice before giving your programmer to design the UI
Why you should think twice before giving your programmer to design the UI
Mikhail Payson
 
Как отучить программиста колбасить (Прагматик 2012)
Как отучить программиста колбасить (Прагматик 2012)Как отучить программиста колбасить (Прагматик 2012)
Как отучить программиста колбасить (Прагматик 2012)
Mikhail Payson
 
как воспитать программиста (Выступление в Sibirix)
как воспитать программиста (Выступление в Sibirix)как воспитать программиста (Выступление в Sibirix)
как воспитать программиста (Выступление в Sibirix)
Mikhail Payson
 
Эффективная работа команды: поток
Эффективная работа команды: потокЭффективная работа команды: поток
Эффективная работа команды: поток
Mikhail Payson
 
Как воспитать программиста
Как воспитать программистаКак воспитать программиста
Как воспитать программиста
Mikhail Payson
 

More from Mikhail Payson (9)

Промышленная разработка ПО. Лекция 8. Особенности работы руководителя проекто...
Промышленная разработка ПО. Лекция 8. Особенности работы руководителя проекто...Промышленная разработка ПО. Лекция 8. Особенности работы руководителя проекто...
Промышленная разработка ПО. Лекция 8. Особенности работы руководителя проекто...
 
Промышленная разработка ПО. Лекция 7. Особенности работы руководителя проектов
Промышленная разработка ПО. Лекция 7. Особенности работы руководителя проектовПромышленная разработка ПО. Лекция 7. Особенности работы руководителя проектов
Промышленная разработка ПО. Лекция 7. Особенности работы руководителя проектов
 
Пара слов о рисках
Пара слов о рискахПара слов о рисках
Пара слов о рисках
 
Руководитель - это про людей (CIOConf 2013, Барнаул)
Руководитель - это про людей (CIOConf 2013, Барнаул)Руководитель - это про людей (CIOConf 2013, Барнаул)
Руководитель - это про людей (CIOConf 2013, Барнаул)
 
Why you should think twice before giving your programmer to design the UI
Why you should think twice before giving your programmer to design the UIWhy you should think twice before giving your programmer to design the UI
Why you should think twice before giving your programmer to design the UI
 
Как отучить программиста колбасить (Прагматик 2012)
Как отучить программиста колбасить (Прагматик 2012)Как отучить программиста колбасить (Прагматик 2012)
Как отучить программиста колбасить (Прагматик 2012)
 
как воспитать программиста (Выступление в Sibirix)
как воспитать программиста (Выступление в Sibirix)как воспитать программиста (Выступление в Sibirix)
как воспитать программиста (Выступление в Sibirix)
 
Эффективная работа команды: поток
Эффективная работа команды: потокЭффективная работа команды: поток
Эффективная работа команды: поток
 
Как воспитать программиста
Как воспитать программистаКак воспитать программиста
Как воспитать программиста
 

Промышленная разработка ПО. Лекция 6. Особенности работы системного аналитика

  • 1. Лекция 6. Особенности работы системного аналитика ПРОМЫШЛЕННАЯ РАЗРАБОТКА ПО
  • 2. • Кто такие системные аналитики? • Цели и задачи аналитика в проекте • Особенности первичного анализа системы • Участие аналитика в процессе разработки • Качества, необходимые аналитику О ЧЁМ БУДЕМ ГОВОРИТЬ СЕГОДНЯ
  • 3. СИСТЕМНЫЙ АНАЛИТИК - ЭТО Специалист в области анализа предметной области и формулирования требований к разрабатываемым информационным системам и прикладному программному обеспечению
  • 4. • Формирование полных, непротиворечивых и актуальных требований к системе • Соответствие разрабатываемой системы ожиданиям пользователя ЦЕЛИ АНАЛИТИКА Проф. стандарт «системный аналитик»: http://www.apkit.ru/committees/education/meetings/standarts.php
  • 5. • Исследование предметной области системы • Детальное описание системы и составление соответствующей документации • Формирование требований к системе • Поддержание требований в актуальном состоянии • Взаимодействие с заказчиком и командой разработки ОСНОВНЫЕ ЗАДАЧИ
  • 6. • Написание проектной документации • Декомпозиция задач для первичной оценки трудозатрат • Создание макетов пользовательского интерфейса ДОПОЛНИТЕЛЬНЫЕ ЗАДАЧИ
  • 7. Аналитик отвечает за то, ЧТО будет сделано в то время, как команда разработки за то, КАК это будет сделано СЛЕДСТВИЕ 1
  • 8. Успех проекта напрямую зависит от того, насколько хорошо аналитик проработал требования СЛЕДСТВИЕ 2
  • 9. Более половины всех неудач проектов связаны с проблемами в управлении требованиями: неполные требования, бесконтрольные изменения и т.д. ФАКТ О ПРОВАЛЕ ПРОЕКТА
  • 10. SPIN-OFF: ВАРИАНТЫ ОПЛАТЫ ЗАКАЗНОЙ РАЗРАБОТКИ
  • 11. • Оплата производится по факту затраченных часов • Изменения оплачиваются в общем потоке • Обычно оплата производится периодически • Стоимость проекта рассчитывается до его старта • Каждое отклонение от ТЗ рассматривается как изменение и добавляется в общую стоимость • Оплата приурочена к контрольным точкам проекта ВАРИАНТЫ ОПЛАТЫ ЗАКАЗНОЙ РАЗРАБОТКИ Fixed Price Time & Material
  • 13. • Общение с заинтересованными лицами • Понимание задач, решаемых пользователями • Моделирование бизнес- процессов предметной области • Исследование решений, которые используются в данный момент ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
  • 14. • Описание общего списка функций системы • Детальное описание каждой функции • Уточнение деталей у заказчика • Описание ограничений и нефункциональных требований • Согласование списка функций с заказчиком или заинтересованными лицами ФОРМИРОВАНИЕ ТРЕБОВАНИЙ
  • 15. • Уточнение неясных деталей • Выяснение его видения отдельных функций и системы в целом • Выяснение нефункциональных требований • Утверждение спецификации • Трансляция вопросов команды ВЗАИМОДЕЙСТВИЕ С ЗАКАЗЧИКОМ
  • 16. • Доведения требований до каждого разработчика (постановка задачи) • Объяснение непонятных моментов в требованиях • Решение спорных вопросов • Консультация тестировщика ВЗАИМОДЕЙСТВИЕ С КОМАНДОЙ РАЗРАБОТКИ
  • 17. Аналитик – представитель заказчика в команде разработки СЛЕДСТВИЕ 3
  • 19. • Заказчик предоставляет заявку на предложение (Request for proposal) • На основе RFP аналитик формирует видение системы и задаѐт уточняющие вопросы • Заказчик даѐт ответы на вопросы • Аналитик предоставляет коммерческое предложение (proposal): видение проекта и грубую оценку трудозатрат • При удовлетворении заказчика запускается фаза анализа системы ПРОЦЕСС ПЕРВИЧНОГО АНАЛИЗА ПРИ ЗАКАЗНОЙ РАЗРАБОТКЕ • Аналитик детально прорабатывает требования к системе • Заказчик предоставляет дополнительную информацию и вносит коррективы • Заказчик утверждает ТЗ • Аналитик формирует список функций системы, после чего производится их финальная оценка вместе с командой разработки • Разрабатывается архитектура системы Предпродажная фаза (presale) Фаза анализа* В зависимости от методологии разработки содержание фазы анализа может меняться
  • 20. • RFP иногда содержит всего пару абзацев • Подготовка коммерческого предложения идѐт в очень сжатые сроки • Часто работа идѐт в условиях жѐсткой конкуренции • Первичная оценка может в несколько раз отличаться от финальной (обычно – в меньшую сторону) ОСОБЕННОСТИ PRESALE-ФАЗЫ При работе на аукционных площадках доля выигранных проектов ~3%
  • 21. • Чем детальнее будет проработаны требования, тем меньше проблем возникнет в ходе разработки проекта • Самая большая опасность для проекта – необходимые требования и функции, отсутствующие в ТЗ • Требования обязательно будут меняться в процессе разработки. Важно управлять этими изменениями ОСОБЕННОСТИ ФАЗЫ АНАЛИЗА Некоторые методологии не предполагают отдельную фазу анализа
  • 22. ПОДДЕРЖКА СИСТЕМЫ В ПРОЦЕССЕ РАЗРАБОТКИ
  • 23. • Требования для функции должны быть сформированы к началу её разработки • В процессе разработки требования к системе не раз претерпят изменения • Новые требования должны обрабатываться и добавляться в систему таким же образом, как первоначальные • Требования должны быть понятными всем участникам проектной команды ОСОБЕННОСТИ АНАЛИТИКИ ВО ВРЕМЯ РАЗРАБОТКИ
  • 24. ЕЩЁ РАЗ О СТАТИСТИКЕ • 51% всех провалов проектов случается из-за некачественного управления изменениями требований • 48% всех провалов проектов случается из-за неправильной оценки трудозатрат (в том числе из-за неучтѐнных функций Роберт Гласс: «Факты и заблуждения профессиоального программирования» http://www.ozon.ru/context/detail/id/3707281/
  • 25. • Способность увидеть систему с точки зрения пользователя • Дотошность, внимание к деталям • Способность увидеть скрытые функции системы • Способность разговаривать на языке как заказчика, так и разработчиков • Навыки технического писателя • В большинстве случаев – знание английского ОСНОВНЫЕ НАВЫКИ СИСТЕМНОГО АНАЛИТИКА