Форум Сообщества Аналитиков

×


Просмотр сообщений

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


Сообщения - Trigger

Страницы: « 1 2
16
Форум подразумевает общение на всех уровнях как сугубо практическом, там и теоретическом. Не вижу никаких преград обсудить идеализированную ситуацию. Форум открыт для свободного общения (в рамках тематики и правил) если тема интересна, есть мнение у вас есть право его высказать.

Должностная инструкция на мой взгляд очень важный и нужный документ. Иначе получится как в http://alex-aka-jj.livejournal.com/66984.html надуй шарик в форме кошечки, а так можно и нужно сослаться на должностную инструкцию.

17
div хорошо бы рассмотреть задачу со всех точек зрения :)
div существует такой документ как должностная инструкция, в котором подробно написана зона ответственности конкретной должности.
Например у меня было инженер II категории, инженер I категории и документ в связи с этим раза в 1,5 утолщается, хотя по факту задачи не сильно отличались.
Особо стало интересно когда на собеседовании на мой вопрос в связи с чем открыта вакансия ответили, что как такового аналитика у них нет, эти задачи выполняет архитектор и очень хочет от них отделаться.

Интересно а обратная ситуация бывает? Когда в команде нет архитектора, его задачи приходится выполнять аналитику.

После схемы Д.Бескова о ролях аналитика, мне стало все понятно. Возможно у кого то будут какие либо дополнения, комментарии к этой схеме.

p.s.Сейчас читаю обязанности на одну вакансию аналитика, в т.ч. "координация взаимодействия подразделений, участвующих в проекте". Завтра на собеседовании уточню: то ли управления требованиями, что подразумевается на должности аналитика, то ли уже изначально говорят, хоть и называется вакансия аналитик будешь еще за ПМ работать.

18
div Это все понятно. Я же хочу рассмотреть команду в которой присутствуют все перечисленные должности. Команда специалистов, каждый в своей области согласно "нашивки" и записи в трудовую.

19
p_safin то, что надо! Спасибо большое!

Elfх Ролей можно множество добавить/придумать.
"Оценщик трудозатрат" как отдельный персонаж впервые слышу. Неужели где-то есть такие специализированные должности? Полагаю что это входит в обязанности или аналитика или менеджера проекта.

Так же можно добавить эксперта предметной области, программистов, внедренцев.

20
Galogen Большое спасибо за ответы.

Дополнительно хотелось бы узнать объем работ, ответственность и относительный уровень зп каждой из ролей.
Насчет ответственности, если провал/срыв сроков случится по вине данного специалиста каковы санкции? Лишение премии/бунусов или что-то еще?
Поскольку с аналитиком наиболее понятно примем его уровень зп за 100%
Сколько по вашему должен получать архитектор и менеджер проекта?

21
Скачал, просмотрел книгу С. Орлов "Технологии разработки программного обеспечения".
К сожалению описание ролей в ней отсутствуют, однако некоторые определения меня заинтересовали:
с.214
Цитировать
  •    Анализ — преобразование требований к системе в классы и объекты, выявляемые в предметной области;
  •    Проектирование — создание статического и динамического представления системы, выполняющего выявленные требования и являющегося эскизом реализации

Разве классы/объекты не являются статистическим и динамическим представлением системы?
p.s.Нашел видеолекции http://www.youtube.com/watch?v=wB6rfqxRKn0 может что интересного узнаю.

22
В том то и дело что зоны ответственности имхо пересекаются. Поэтому и хочу понять где же проходит граница между аналитиком и архитектором.
Куда например относятся диаграммы компонентов и развертывания UML? Кто их должен делать?
У нас в ТЗ указывалось все вплоть до формата отдельных команд и их взаимодействия, т.е. оставалось, что называется закодить. Где же в этом случае работа архитектора?
Или напр. 3.Обоснование необходимости внедрения, смета затрат, предполагаемый экономический эффект и время окупаемости; Это обязанность аналитика из менеджера проекта?
Хотелось бы по пунктам определись зоны ответственности каждого.
Спасибо за рекомендацию книги. Почитаем.

23
Продолжение планируется?

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

Цитировать
RUP - типичная каскадная модель
Что-то новенькое. RUP изначально предполагает процессы и итерации, в отличии от каскадной, где фазы идут в стогом порядке.
Цитата из википедии:
Цитировать
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.
Цитировать
Водопадная модель жизненного цикла предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

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

Другое дело, если заказчик заинтересован полностью участвовать в разработке. Тогда наиболее подходит ХР.

p.s.Если заказчик хочет по ГОСТу странно будет говорить, что мы используем ХР как самый передовой метод и ваше постоянное присутствие нам жизненно необходимо, раз в 2-4 недели будем высылать очередную версию (ну что успели к этому моменту, независимо от количества багов). Такому заказчику альфа, бетта версии не нужны, только полностью законченный продукт! Если в срок не укладываются или реализована не вся функциональность, то проблемы разработчиков. Если появились новые требования не указанные в ТЗ, то это проблемы заказчика.

25
Добрый день коллеги.
Читаю всякие красивые статьи, что каскадная модель это прошлый век, сейчас надо использовать итерационные модели (RUP, Agile, etc.)
Как мне представляется процесс разработки ПО:
1.Заказчик что-то хочет
2.Пишется ТЗ.
3.Заказчик согласовывает и утверждает ТЗ.
.
.
n.По истечению определенного времени получает требуемый продукт с характеристиками указанными в ТЗ.

Срыв сроков/ досрочная сдача указываются в договоре (пени, бонусы)
Внесение изменений после утверждения ТЗ оформляются дополнительным соглашением с указанием изменения стоимости/сроков.

т.е. заказчик после утверждения ТЗ, по истечению указанного времени ожидает получить готовый продукт. Смысл участия заказчика в процессе разработки ПО?

p.s.Я работал в ВПК. У нас чуть ли не каждая версия ПО как НИР шла. Соответственно новое полноценное ТЗ на каждую новую версию, хотя 90% может повторятся с предыдущей.

26
Добрый день уважаемые коллеги.
Предлагаю обсудить зоны ответственности каждой из ролей при создании ПО.

Зона ответственности аналитика:
1.Обследование предметной области;
2.Определение требований;
3.Обоснование необходимости внедрения, смета затрат, предполагаемый экономический эффект и время окупаемости;
4.Разработка ТЗ; подготовка сопроводительной документации;
5.Создание необходимые диаграмм;
6.Разработка шаблонов проектирования;
7.Разработка тест-кейсов;
8.Участие в тестировании и сдаче продукта заказчику;
9.Участие во внедрении и сопровождении программного продукта.
------------------------------------------------------------------
Следует учесть, что ТЗ может включать в себя диаграммы компонентов и развертывания.
Касательно BPMN 2 довольно сложно определить зону ответственности аналитика и разработчика.

Учитывая вышесказанное, так что же входит в зону ответственности архитектора и менеджера проекта?

p.s.Если что то забыл для аналитика дополните пожалуйста.
p.p.s.Также прошу поправить по терминологии.

Страницы: « 1 2