1396

Задачи студентов / Re: Схема работы лифта - кто хочет потренироваться?

« : 31 Января 2012, 08:35:59 »

может начать с ДВИ? 

Мдя, Остапа понесло (с)

1397

Конференции Семинары и Тренинги / Re: ЛАФ-2012 будет?

« : 28 Января 2012, 17:46:22 »

А что такое EARS?

Easy approach to requirement syntax

1398

Задачи студентов / Re: Схема работы лифта - кто хочет потренироваться?

« : 27 Января 2012, 21:00:10 »

Задача, как я понимаю, в том, чтобы разработать эффективную систему управления двумя лифтами и построить модель с использованием языка UML?

Виктор, думаю. Вы уже присоединились к задаче. Начинаете задавать вопросы для снятия неопределенности: типичная задача для аналитика.

1399

Конференции Семинары и Тренинги / Re: ЛАФ-2012 будет?

« : 27 Января 2012, 20:55:37 »

Мы можем уже начинать искать докладчиков, но в теме про докладчиков так никто и не отписался, видимо никто и ничто никому не интересно (

Задача программного комитета такую программу дать, т.е. показать меню. Действительно трудно сказать, что хочется услышать. Люди хотят делится опытом.

Мне интересна тема EARS, опыт его влияния на качество аналитической работы.
Мне интересны перспективы развития отрасли ИТ в России и ближайшем окружении.
Мне интересны темы: вызовы современности по отношению к ИТ.
Мне интересны темы успешной организации работы с требованиями на всех уровнях разработки.
Да много чего интересно

Кто готов взять роль главного программиста, т.е. формирователя программы?

Все таки хотелось бы вначале определится когда и где. Однако думаю это должен быть достаточно авторитетный человек и имеющий обширный кругозор и  знакомства.

1400

Конференции Семинары и Тренинги / Re: ЛАФ-2012 будет?

« : 27 Января 2012, 16:51:57 »

Ну и?

Самому что ли пойти в организаторы?

Ждем Михаила Смирнова. Он обещал быстро нам сказать о возможности провести все в Костроме.

Мы тоже предложение сделали. Иваново (как прежде). 23-24 июня. или 30 июня -1 июля.
допвозможности этого сезона:
- организация обедов в местной столовой с частным поваром (о стоимости обедом поговорим)
- нанять повара для вечеринки

Месяц года уже прошел. Мы теряем время. Я считаю в феврале нужно активнее работать по программе. Искать интересных докладчиков. Потому нужно определиться со сроком и местом.

1401

ПО Аналитика / Re: Средство проектирования для PHP

« : 26 Января 2012, 08:10:21 »

А для javascript-a?

http://www.visual-paradigm.com/ - ответы на ваши вопросы

1402

Sparx / Re: Версионность и ветвление ЕА в БД

« : 26 Января 2012, 08:09:08 »

селен

это такой химический элемент, говорят в микрозначениях очень полезен и необходим для здоровья

1403

Sparx / Re: Версионность и ветвление ЕА в БД

« : 25 Января 2012, 13:08:15 »

Согласно статье

Или есть другие способы?

А почему бы не задать этот вопрос непосредственно на форуме производителя.

1404

Sparx / Re: FAQ - Sparx Enterprise Architect

« : 23 Января 2012, 15:32:42 »

Спасибо за Ваши предложения и комментарии

1405

Методологии / Re: В чем преимущество итеративног процесса разработки ПО?

« : 23 Января 2012, 15:30:06 »

Небольшое замечание.

Сергей, спасибо за уточнение.

1406

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 23 Января 2012, 10:30:30 »

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

Так это типичная ситуация. В чем проблема-то?

Куда например относятся диаграммы компонентов и развертывания UML? Кто их должен делать?

Точно уж не аналитик. ДК и ДР - типичные архитектурные диаграммы. Делает их проектировщик, т.е. человек который умеет отвечать на вопросы: из каких компонентов будет состоять система? где будут размещены части системы?

У нас в ТЗ указывалось все вплоть до формата отдельных команд и их взаимодействия, т.е. оставалось, что называется закодить. Где же в этом случае работа архитектора?

Не следует переносить частную практику на весь опыт. ТЗ - это в первую очередь доумент соглашения, а не задание кодеру на реализацию.
Даже если следовать ТЗ - то есть стадия технорабочий проект, который как я чувствую Вы засовывает в ТЗ.

Или напр. 3.Обоснование необходимости внедрения, смета затрат, предполагаемый экономический эффект и время окупаемости; Это обязанность аналитика из менеджера проекта?

думаю менеджера проекта при активном участии аналитика

Хотелось бы по пунктам определись зоны ответственности каждого.

где-то на форуме и в сети гуляет документ обязанностей и компетенций системного аналитика. Кроме того посмотрите википедию. И вообще Вы обращаетесь по таким очевидным вопросам, материал по которым имеется в избытке. Find it

Разве классы/объекты не являются статистическим и динамическим представлением системы?

не являются. являются статическим

1407

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 22 Января 2012, 22:30:30 »

Если кверент

Ida, ну к чему эти словечки. Русский достаточно богат и сам по себе

1408

Методологии / Re: В чем преимущество итеративног процесса разработки ПО?

« : 22 Января 2012, 12:08:10 »

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

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

Я о Вас ничего не знаю кроме того, что Вы пишите о себе сами.

Что ж примем как аксиому. У Вас нет никакого опыта разработки ПО. Я предлагаю Вам его приобрести. Начните создавать ПО для кого-нибудь, желательно в команде из нескольких человек.

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

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

RUP - это фреймверк, это попытка дать инструмент команде разработчика, с помощью которого она могла бы выстраивать управляемый процесс производства ПО. 4-6 недельные итерации типично заканчиваются релизами, довольно законченными версиями продукта. Внутри этих 4-6 и более недельных итераций идет цикл разработки типичный для каскада

1409

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 22 Января 2012, 01:34:13 »

Мое имхо,
зона ответственности аналитика понять ЧТО требуется заказчику для решения его проблемной ситуации и предложить концепцию решения. Т.е. это аналитическая деятельность.

Действительно, аналитик готовит ТЗ, постановки, ТК, внедряет и сопровождает продукт. Участвует в обсуждении проектных решений. Но пункт 6 не компетентность аналитика, а архитектора.

Архитектор - это тоже аналитик системный, но он и разработчик, опытный программист с хорошим стажем. Его задача предложить решение встраиваемое в имеющуюся архитектуру, либо создание новой архитектуры. Архитектор генератор проектных требований более низкого уровня.

Менеджер проекта - по существу главный аналитик проекта, его главная задача управление процессом, его организация, планирование, контроль, прогнозирование, оперативное управление, ...

1410

Методологии / Re: В чем преимущество итеративног процесса разработки ПО?

« : 22 Января 2012, 01:26:06 »

Trigger, вообще довольно странно от Вас с Вашим то опытом слышать подобные рассуждения и вопросы. Хотя может все дело именно в ВПК?

RUP - типичная каскадная модель, что нисколько не запрещает итеративного процесса. Agile - это целый спектр методик и методологий, это скорее принцип, чем модель. Agile базируется на опыте и предполагает большую адаптивность. По сути он предлагает выбирать методологию разработки для конкретного проекта.

Итеративный процесс предполагает эволюционную модель Боэма.
Преимущества:
- вовлечение заказчика в процесс разработки
- эволюционное протипирование и эволюция поставки работающего кода
- принцип ограничения работ

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

Водопадная модель как показывает практика плохо работает в производстве ПО (по крайней мере коммерческого ПО)