Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Рабочая тетрадь_системный анализ_24апр.docx
Скачиваний:
35
Добавлен:
22.02.2015
Размер:
470.51 Кб
Скачать

5

Рабочая тетрадь

15.04.2014-15.06.2014

Конспект

Краткий конспект курса «Системный анализ», рабочая тетрадь с заданиями

Системный анализ, заказная разработка



Всем привет!

Меня зовут Даша Бакирова, мне 27, я системный аналитик.

Я специализируюсь на заказной разработке, много работала с крупными заказчиками (Транснефть, Росэлетроника и т.д), много фрилансила, теперь могу сказать точно: быть аналитиком – это интересно и здорово. Я очень рада, что мы создали этот курс, и теперь я могу поделиться с вами своими находками, опытом, любимыми профессиональными книгами, удобными инструментами, «Избранным» с Хабра и прочими полезными штуками.

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

Вводное занятие

  • Процесс разработки программного обеспечения

  • Задачи аналитика в заказной разработке

  • Качества и навыки аналитика

  • Важные термины

  • Область проблем и область решений

Процесс разработки программного обеспечения

Типичный процесс разработки приведен на рисунке ниже (см. Рисунок 1).

Рисунок 1 ─ Типовой процесс разработки ПО

Задачи аналитика в заказной разработке

Аналитик в проекте есть всегда, даже если формально этой должности нет. Это тот человек, который разрабатывает требования и управляет ими, который представляет перед бизнес-пользователями разработчиков, а перед разработчиками – бизнес пользователей.

В процессе заказной разработки аналитик контактирует с заказчиком, проводит предпроектное обследование, разрабатывает требования, разрабатывает и защищает ТЗ, пишет постановки программистам и дизайнерам, представляет новый функционал заказчику и фиксирует замечания, управляет изменяющимися требованиями, внедряет систему.

Минимальные знания, необходимые аналитику:

  • представление о процессе разработки ПО;

  • методологии разработки ПО;

  • представление о моделировании;

  • ГОСТы;

  • основы ООП;

  • паттерны проектирования;

  • нотации и case-средства;

  • представление о базах данных и языке sql.

Качества и навыки аналитика

Аналитик работает с людьми, документами и системами.

Для работы с документами необходимы:

  • умение обрабатывать большой объем информации;

  • способность написать вменяемый текст;

  • умение читать схемы;

  • умение понимать канцелярит .

Для работы с людьми необходимы:

  • умение установить контакт;

  • наблюдательность;

  • умение слушать

  • умение задавать вопросы

  • умение рецензировать требования

  • терпение

  • решительность

  • способность выступать публично

Для разработки систем требуются:

  • умение переводить с естественного языка на технический

  • умение писать use case

  • умение понимать разработчиков

  • умение моделировать

  • представление о хорошем интерфейсе

  • умение видеть исключения

  • способность внедрить систему

  • умение читать код

Важные термины

В любом проекте аналитику встречается ряд важных слов. Эти слова приведены на схеме ниже.

Очень важно четко понимать значения этих слов.

  • Цель ─ нормированное представление о достижимом результате.

  • Задача ─ действие, направленное на достижение цели, которое должно быть выполнено к определенному сроку.

  • Проблема ─ препятствие, мешающее достижению цели.

  • Решение ─  набор изменений текущего состояния организации, которые производятся для достижения бизнес потребностей, решения проблемы, или получения преимуществ возможностей.

  • Возможности ─ направления развития.

  • Ограничения ─ правила или свойства чего-либо, ограничивающие направления развития.

Область проблем и область решений

Часто сами аналитики не понимают, зачем они разрабатывают те или иные функции в системе.

Пример: Иван решил открыть магазин, ему нужно будет регистрировать и впоследствии обрабатывать заказы. Какие решения мы можем ему предложить?

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

На схеме представлена область проблем и область решений.

Выводы:

  • У каждого процесса есть текущее и желаемое состояние. Желаемого состояния можно добиться разными способами, иногда систему разрабатывать необязательно. Преждевременный переход в область решения сужает круг возможных вариантов решения задачи.

  • Нет гарантии, что выбрана самая эффективная реализация.

Особенности:

Количество требований может расти. Чем больше возможностей, ограничений, чем более детализированы требования, тем меньше решений мы можем найти.

Рабочие ситуации:

  1. Нужно обследовать предметную область, выявить проблемы и найти решение.

  2. Проблемы выявлены (чаще есть ТЗ), нужно предложить разные решения и согласовать одно.