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

×


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

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


Темы - Kavalsky

Страницы: 1
1
Пол: не важен
Возраст: до 35 лет.
Образование: Высшее, оконченное.

Факультеты/Навыки:
Важно: информатика/программирование
Вторично: математика/экономика и/или педагогика/психология

График:
Полный рабочий день. 9:30 - 18:00, возможно смещение.

Требования:
- Опыт программирования на любом языке.
- Пытливый ум, внимание к деталям, желание самостоятельно разбираться в предметной области, склонность к аналитическому мышлению.
- Понимание сетей и сетевых технологий
- Английский – Техническая литература.
- Свободное общение с людьми. Проактивность и инициативность приветсвуются!

Обязанности:
Первые 3-6 мес интенсивное изучение информации, вхождение в предметную область, далее администрирование специализированного банковского АПК (в основном software), поддержка пользователей, обновление, внедрение и тестирование модулей .
Возможность развивать свои знания и навыки в данной предметной области. В зависимости от предрасположенности, возможна специализация (не ранее чем через год) в более узкое направление: техподдержка, программирование (Delphi), тестирование,  аналитика.


м. Новослободская - Достоевская

Оформление в штат.
Дотации на питание.
ЗП достойная!

kavalsky@list.ru


2
В виду того что на данный момент не все теории и практики охвачены моим познанием хотел бы структурировать имеющиеся методологии, теории, стандарты и иже с ними.
Правильно ли я понимаю, что:
Следует разделять «сущности» (не исключено что я их перемешал)
1.   Нотация  (Методология?) сбора/анализа/моделирования (или это три разных подразделения)
SADT, UseCase, UML, есть еще популярные ?
2.   Методологию разработки ПО
RUP, Iconix, Agile, XP, и т.п.
3.   Стандарты представление документации
ГОСТ, IEEE, есть еще популярные ?

В итоге
1. мы используем методологию моделирования для сбора/моделирования/представления/хранения данных
2. с помощью методологии разработки мы управляем процессом создания продукта
3. с помощью стандарта представления документации мы передаем заказчику информацию о данных и о продукте

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

Как следствие:
1.   Понятие о «Спецификации требований» у каждой компании может быть свое, как и состав документов, но если это ГОС проект то смотрим соответствующий 34-ый стандарт и никаких вам спецификаций.
2.   По большому счету ВИ есть ФТ и наоборот. Т.е. одно порождает другое и уже от нас и проекта зависит от чего мы пляшем. Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ? Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?

3
На просторах работодателей бывают волшебные вакансии в которых в должность СА входит пресейл, работа с базами данных (Знание SQL), тестирование и даже кодирование.

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

Аналитик должен описывать:
Прецеденты, Функц. треб., Биз. треб., Пользов. треб.

Аналитик НЕ должен описывать :
Нефункц. треб., тестовые сценарии, классы, интерфейсы и реакции системы (кроме Пользов. треб.), модель БД, код и т.п.


Как должно быть:
Аналитик - Описывает как хочет работать Заказчик
Пишет"Пользователем могут быть Коля, Вася. Петя. они могут создать документ с такими ... атрибутами"

Архитектор - архитектуру системы, на чем она будет, с какой БД, какими паттернами и проч концепт.

Тим-лид - Описывает КАК ДОЛЖНА РАБОТАТЬ СИСТЕМА что должны накодировать программисты.
Пишет "По нажатию кнопки Создать создается объект документ типа Договор. Сохраняется в БД в таблице Договора. Пользователь может редактировать документ, может не редактировать, у него такие-то инструменты, ограничения документа по следующим атрибутам, если они не заполнены выдается ошибка, редактирование может окончится удалением документа в случае ... И Т.П."

Тестировщики - тест кейсы на основе прецедентов.


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

На выходе аналитика (опционально, от проекта) три документа:
1. ТП - границы проекта, бизнес цели задачи и прочее предпроектное обследование результат работы всей команды пресейла. Может быть больше или меньше напичкано инф.
2. Прецеденты - они же ВИ со ссылками на требования.
3. Функциональные, бизнес, пользовательские требования, пронумерованные. Их управление, изменение, трассировка, и проч по желанию.

А уже из п. 2 и 3 тим-лид пишет постановки программистам, а те код.


4
Приветствую коллеги.

Собственно пришло время и желание расти профессионально, пришел к Вам за наставлением и вектором тяги.

На данный момент используемый инструментарий - Visio + Word + Excel (спасибо тебе Мелкософт), поверхностные знания методологий и нотаций, опыт написания спецификаций в больших и малых интеграторах с полным или частичным бардаком в орг структуре и процессе разработки требований, да и ПО.

Хочется поменять или положение вещей в компании или компанию.
По методологиям и нотациям все немного проще, читаю Карла Вигерса, Алистера Коберна и Википедию с Вашим форумом :)

А вот с инструментарием, ПО у меня вопрос, точнее затык.
На данный момент пришло понимание, что нужно мне:
- Case средство (Наверно ЕА)
- Средство управления требованиями (Наверно R Requisite)
- Нужно чтобы они были в первую очередь популярными и во вторую попроще осваиваемыми.
- Может быть я еще не пришел к чему-то еще ? Может есть еще какие-то автоматизаторы, улучшайзеры и т.п.? (ну учитывая мой "стартап")


Вопросы:
1. Какие фичи дает ЕА (Или другое Case средство) кроме редактора диаграмм. Я предполагаю что много интересного, но понять и найти как этим пользоваться пока не могу (ну я всего 3 дня над ним бьюсь)?
2. Какие продукты выбрать? (временно можно попиратить, потом купим или купЯТ).


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

Роль свою вижу как Системный аналитик, может быть немного Бизнес аналитики (так как у нас, обычно, эти должности неделимые. Еще и разработчик и тестер и пресейл бывает, но я таких вариантов не ищу).

По данным продуктам нет ничего на русском, по этому первый раз в жизни сел и прочел пару глав хэлпа. Понятно, но не все. Курю форум, лопачу Вики и гугл.

Надеюсь на ясность изложения (можно оценить мои аналитические способности кстати :)) и на Вашу помощь.

Спасибо заранее!

Страницы: 1