Технологии создания ПО

← →
handra (2003-03-28 16:00) [0]

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

← →
Mystic (2003-03-28 16:56) [1]

http://www.xprogramming.com/

← →
handra (2003-03-28 18:56) [2]

Mystic © (28.03.03 16:56)
http://www.xprogramming.com/
Кратко, а опыт внедрения в Россим есть? На мой взгляд, абсолютно безперспективная вещь.

← →
Внук (2003-03-28 19:52) [3]

>>handra © (28.03.03 18:56)
Угу, буржуйские технологии нам не подходят, у России свой особый путь :)))) На задворках...

← →
Mystic (2003-03-28 22:10) [4]

Был сайт www.xprogramming.ru, но сейчас попасть на него не могу :( Там были и опиания опыта внедрения XP в России. Ряд книжек по XP переведен на рус. язык. Мне кажеться, что для России это имеет смысл. Смотри в эту тему Agile-технологии. В любом случае книгу К. Бека "Экстремальное программирование", имхо, следует прочесть, если уж ты этим интересуешься.

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

Есть еще MSF, то от него я не в восторге.

Что конкретно из XP тебе кажется безперспективным.

← →
Palladin (2003-03-28 23:12) [5]

> абсолютно безперспективная вещь.

это на твой взгляд, одним глазом из под полузакрытого века?

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

← →
whitefoot (2003-03-29 14:51) [6]

to Mystic
http://www.xprogramming.ru - ссылка работает!

← →
Mystic (2003-03-29 15:14) [7]

> to Mystic ссылка работает!

Значит вчера был где-то глюк.

← →
Satirus (2003-03-29 15:24) [8]

>почитать про это очень следует, даже если ты не собираешься этим заниматся...
что, больше читать нечего?;)

← →
Shiva1 (2003-03-30 11:31) [9]

На мой взгляд, у большинства групп все же сейчас не стандартизованные, а кастомные процессы, в кторые входят самые различные техники. В нашем процессе много постулатов из XP, но наш процесс - не XP. Это обычный кастомный процесс. И почти в каждой группе дела обстоят подобным образом. Увы, стандартизованные процессы, на мой взгляд, почему-то с трудом приживаются в России.

← →
handra (2003-03-31 13:11) [10]

Shiva1 © (30.03.03 11:31)
На мой взгляд, у большинства групп все же сейчас не стандартизованные, а кастомные процессы, в кторые входят самые различные техники. В нашем процессе много постулатов из XP, но наш процесс - не XP. Это обычный кастомный процесс. И почти в каждой группе дела обстоят подобным образом. Увы, стандартизованные процессы, на мой взгляд, почему-то с трудом приживаются в России.Если не секрет, можно подробнее?

← →
MsGuns (2003-03-31 13:17) [11]

>handra © (31.03.03 13:11)
>Если не секрет, можно подробнее?

Зачем подробнее ? Известно, что в России (в Украине, Беларуссии, Казахстане,..) в каждой лавке - свой устав. Общие (рациональные с т.з. здравого смысла, общепринятых стандартов и пр.) алгоритмы "не катят". Все нужно доделывать, а иногда и переделовать "под Семен Семеныча" или "Клавдию Петровну".

← →
MsGuns (2003-03-31 13:25) [12]

Еще тема. Почему в СНГ не приживаются (имеется в виду не формальное внедрение, а фактическое использования с разумным в сравнении с затратами эффектом) системы - гиганты типа САП Р3, которые прекрасно зарекомендовали себя на Западе и не только ?

Сплошь и рядом ситуация: АЭС (Комбинат, Завод, ОблАдминистрация и т.д.) "внедрили" эту систему, заплатив сотни тысяч зелени, а бухгалтерия как корячилась на 1С, так и продолжает. Как местные программисты не сидели без работы до системы, так и сейчас не сидят - наоборот, работенки хорошо добавилось. А эффект ? Ну да, плановый отдел что-то там имеет, снабженцы вроде видят чего не хватает, производственники иногда имеют относительно четкую инфу о заделе и наличии на складе сырья и комплектующих. Но, по большому счету, очень часто это все в основном "локально" и "временно". Эффекта, ради которого стОило тратить такие бешеные бабки, не видно и рядом.

← →
handra (2003-03-31 14:50) [13]

MsGuns © (31.03.03 13:17)
>handra © (31.03.03 13:11)
>Если не секрет, можно подробнее?

Зачем подробнее ? Известно, что в России (в Украине, Беларуссии, Казахстане,..) в каждой лавке - свой устав. Общие (рациональные с т.з. здравого смысла, общепринятых стандартов и пр.) алгоритмы "не катят". Все нужно доделывать, а иногда и переделовать "под Семен Семеныча" или "Клавдию Петровну".

← →
handra (2003-03-31 14:52) [14]

А так ли? ГОСТ и ISO не просто так выдумали. В каждой "лавке" свой устав - факт, но положительные факторы возможно окажут благотворное влияние и при внедрении в другую "лавку"...

← →
Shiva1 (2003-03-31 15:20) [15]

Доброго дня.
Я вообще-то говорил не о стандартах, а о процессах разработки. Попробуюпояснить свою мысль. Предположим, есть у нас группа из 20 девелоперов. К ней - необходимое количество менеджеров и арзхитектор, скажем. И вот появляется заказ на 3 месяца, который задействует всю группу. Вопрос - стоит ли этой группе внедрять у себя RUP?
Ответ - чаще всего - вряд ли, ибо RUP достаточно тяжел. Пока будут описаны все необходимые артефакты, правила и граничные условия, пока бдут созданы все доекументы - пройдет не 3, а два раза по 3 месяца, и проект будет провален.
Возьмем XP. Вроде бы, для маленьких и средних проектов - идеальный процесс. НО до сих пор из-за человечского фактора плохо приживается pair-programming и, скажем, ограничение на количество рабочих часов в неделю. Это - тоже отступления от процесса.
Поэтому чаще всего в каждой компании есть свой процесс. который хорошо ей подходит и удовлетворяетклиента. НО этот процесс далеко не всегда стандартизован, ибо переход на стандартизованный процесс - есть огромные затраты по деньгам и времени, и далеко не факт, что он окупится..

← →
Mystic (2003-03-31 15:58) [16]

1. Проектирование перед началом разработки. Детальное проектирование занимает слишком много времени (см. пример выше, когда кодирование начинается на 174-й бизнес-деь проекта). Ни заказчик, ни бригада разработчико к такому в нашей стране не готовы. (Или готовы --- 150 дней бить баклуши, 24 дня писать проект...) Тем более, что по западным меркам, разработка проета обычно проводится одними людьми, кодирование --- другими. В этом случае, если перевести грамотных разработчиков в отдел разработки, то кто будет кодировать? И наоборот, глупо воплошать ошибочные решения. Обычно реализация подобных проектов требует наличия "кодеров", т. е. низкоквалифицированной рабочей силы, которая будет вопрощать идеи проектировщиков. Однако у нас именно "кодеры" являются самой амбициозной частью программеров (ведь они не получают удовлетворения от кодирования), поэтому норовят все время выйти в менеджеры проекта, что, впрочем у них, часто получается...

Недавно я читал книгу Гасана Гомы по COMMET для проектирования real-time систем. Я нашел там сравнительно немного нового. В основном принципы, описаные там, я и так интуитивно применял при проетировании. Зато я нашел для себя ответы на вопросы "почему ты сделал так?" С другой стороны эта книга полезна для тех, кто окончив курсы, может приступать по ней проектировать диаграммы UML для разработчиков... Следуя приведенным рекомендациям можно составлять хорошие модели, при этом не требуется большой творческой отдачи (что весьма приемлимо в условиях запада). в принципе запад очень сильно настроен на то, чтобы привлекать при разработке ПО не творческих всезнаек, какими явлются большое количество отечественных разработчиков, а исполнительных трудяг, причем на всех стадиях.

2. XP хорошо подходит для небольших коллективов (2-15 человек) квалифицированных программистов примерного одного уровня подготовки. По сути это традиционный процесс разработки ПО + несколько идей, которые позволяют повысить качество кода. вообще, код в XP --- это основное средство общения/документации. Сколько бы мне не говорили о важности всяких там диаграмм, но получая новую библиотеку я первым делом просматриваю примеры (75% всей информации). В институте я сначала реализовывал алгоритмы на Паскале или С++, а только потом рисовал их блок-схемы алгоритмы. Мне (и не только мне) так было проще. В ХР все более-менее равны, каждый понемногу занимается проектирвоанием и архитектурой, хотя конечно планирование перед началом разработки никто не отменял, просто это предварительное, а не всеобъемлющее планирование. Именно поэтому, даже если ты не обираешься вводить у себя ХР, я советую изучить эту технологию создания ПО *равно как и другие Agile-технологии).

← →
handra (2003-03-31 17:42) [17]

Mystic © (31.03.03 15:58)
... В ХР все более-менее равны, каждый понемногу занимается проектирвоанием и архитектурой ...
А правильно ли это? Может лучше выделить технолога, руководителя проекта (постановщика обязательно!)?

← →
Mystic (2003-03-31 18:18) [18]

Все зависит от того, какие специалисты имеются в наличии... Я уже описал недостатки традиционного подхода. Добавлю еще, что в 75% случает заказчик сам не знает, что хочет. Поэтому руковолитель проекта/постановщик задач зачастую берут на себя роль заказчика и говорит: "Заказчику нужно то и то", а программисты воплощают. В ХР программисты напрямую взаимодействуют с заказчиком.

Что лучше сказать трудно, но ХР мне более симпатична.

← →
handra (2003-03-31 18:56) [19]

В ХР программисты напрямую взаимодействуют с заказчиком
Откровенно против, программисты могут общать с заказчиком за столом с бутылкой чего-нить ;), а работу с заказчиом должен вести постановщик на стадии написания ТЗ. Опыт подтверждает это...

← →
MsGuns (2003-03-31 19:15) [20]

>handra © (31.03.03 18:56)
>а работу с заказчиом должен вести постановщик на стадии написания ТЗ. Опыт подтверждает это...

И что же говорит Ваш опыт ? Что бухгалтер Марь Иванна должна предъявлять свои претензии программисту через "переводчика" - постановщика (а в идеале еще и разработчика) ?
Опыт реальной работы говорит, что есть Заказчик, а есть Исполнитель. Для Клиента Исполнителем" может выступать и Марь Инвановна, от для Подрядчика - программист Сеня. А если они не будут между собою общаться, то все вопросы (вплоть до того, что кнопка такая-то "вылетает") будут обсуждать Гл.инженер завода и Гл.Разработчик Софтверной фирмы ?

← →
Mystic (2003-03-31 19:32) [21]

Типичный пример (проект разрабатывался без ХР технологии): разратывалось типичное В2В приложение. Большое внимание было уделено представлению информации о фирме, контактых лицах, и т. д. и т. п. Впоследствии выяснилось, что для этой цели вместо набора из 20-ти таблиц вполне хватило бы примечания . А вот с журналом изменений прогадали: пользователь хотел знать что кто, где, когда, что и на что поменял в базе, а наш простой лог основных событий его не устроил. Попытка привинтить к существующей структуре базу еще и логи внесло неразбериху и сумятицу в существующий проект (поплыл бизнес-уровень), что впоследствие его оказалось проще переписать его [бизнес-уровень] заново. Одно из преимуществ ХР --- работа в ситуации, когда заказчик сам не знает, чего хочет. а желания заказчика сформировались уже после показа первой версии, т. е. когда все было спроетировано и продумано на много шаго ввперед (но по нашему видению проблемы)

← →
MsGuns (2003-03-31 19:53) [22]

Да, почитал про XP и ржал полчаса. Оказывается, то, что американы называют "экстремальным", для большинства моих коллег по программерству, и меня самого в том числе, ОБЫЧНЫЕ БУДНИ. Только еще и усугубленные тем, что часто клиент, получив, что хотел (или почти), начинает выпендриваться с оплатой. Бабки приходится "выбивать", и не факт, что успешно.

Времена асупов, когда на проекте сидело по полсотне человеков из десяти отделов, ИМХО, прошли. Разве что еще сохранилась подобная система в динозаврах, жирующих пока еще в условиях общего завала (топливно-сырьевой комплекс, энергетика, центральные органы власти и т.д.)

Сегодня, чтоб реально зарабатывать на хлеб программированием, но при этом "не продаться" началныку в корпорацию, а работать в условиях рынка, надо не просто уметь писать программы, разбираться в бухгалтерии и производстве, знать законы и уметь их "интерпретировать",- надо еще и уметь предлагать клиенту идеи, до которых он еще не дошел и реализовывать их ! Причем, практически в любой области - торговле, производстве, бюджете и т.д. И все это - за весьма скромное (по сравнению с западными) вознаграждение.

← →
handra (2003-03-31 21:06) [23]

MsGuns © (31.03.03 19:15)
>handra © (31.03.03 18:56)
>а работу с заказчиом должен вести постановщик на стадии написания ТЗ. Опыт подтверждает это...

И что же говорит Ваш опыт ? Что бухгалтер Марь Иванна должна предъявлять свои претензии программисту через "переводчика" - постановщика (а в идеале еще и разработчика) ?
Опыт реальной работы говорит, что есть Заказчик, а есть Исполнитель. Для Клиента Исполнителем" может выступать и Марь Инвановна, от для Подрядчика - программист Сеня. А если они не будут между собою общаться, то все вопросы (вплоть до того, что кнопка такая-то "вылетает") будут обсуждать Гл.инженер завода и Гл.Разработчик Софтверной фирмы ?

Пардон, а не пора ли отделить "вопросы кнопок" (что касается проектирования интерфейса) и вопросы функционала ПО, мне, например, как программисто горозда комфортнее работается без двух-трех десятков звонков в день и Марь Ивановны (увы, опыт работы с клиентом был), я прекрасно зная, что мне делать. Если вносятся изменения в проект (читай ТЗ), то предварительно все детали оговариваются постановщиком и я как технолог (по совместительству) решаю способы внесения изменений. Решает в конечном итоге руководитель отдела (он же координатор проекта).
И, как правило, ситуаций, описанных выше (про примечания и двадцать таблиц), не возникает, т.к. постановщик прорабатывает этот вопрос до начала кодирования, а применения ActionLog я как технолог приписываю практически любой задаче...

P.S. Активность в данной ветке слабая, неужели этот вопрос волнует только 5 человек.

← →
MsGuns (2003-03-31 21:47) [24]

>handra © (31.03.03 21:06)
>то предварительно все детали оговариваются постановщиком и я как технолог (по совместительству) решаю способы внесения изменений.

Ага, звучит красиво ! Даже в условиях корпорации (а Вы, видимо, работаете в крупной конторе, где есть эти самые "постановщики", "разработчики", "программисты", "кодеры-операторы" и т.д., т.е. целый отдел/отделы) это все выполняется на бумаге (12 лет работал в отделе АСУ крупного завода,- знаю не понаслышке). А вот если все эти "должности", все вместе - в "одном стакане", т.е. в одном человеке ? При этом у него может быть даже несколько помощников. А подобных проектов-задач - штук 5 (у меня был случай, когда писал 3 новых, дорабатывал еще 2, и доп-но в штуках 3-х шел разбор полетов - там была опытная)

Если речь идет о новом проекте, который разрабатывается "самостийно", т.е. без указания начальства, да часто такового вообще нет (как у меня, к примеру) и задача стоит новая (недавно, к примеру писал прогу для Госархива - вообще новое для меня),- так что ж делать - искать постановщика и разработчика ? И платить им деньги (и немалые) ? Можно и так, но тогда что останется мне и моим коллегам ? Или поднять цену разработки в разы ? Тогда клиент просто-напросто откажется и все.

← →
handra (2003-04-01 10:36) [25]

MsGuns © (31.03.03 21:47)
Кстати, меня интересует именно разработка крупных проектов (КИС/ИС/АС/ИР), которые по определению не могут быть разработаны "самостийно".
А стоимость работы постановщика, к примеру у нас, меньше, нежели программиста-технолога...
По-поводу "выполняется на бумаге" - это к вопросу "А оно Вам нужно?". Задача, стоит в том чтобы вывести это на нормальный уровень, повысить эффективность работы - многое зависит имеено от организации тех. процесса. А кроме ссылок на модное ныне XP и нездоровой критику я здесь ничего не прочитал. Печально... :(

← →
stone (2003-04-01 10:44) [26]

> А стоимость работы постановщика, к примеру у нас, меньше,
> нежели программиста-технолога

Странное сочетание
> программиста-технолога...

А вообще аналитика и постановка задачи всегда ценятся больше, чем кодирование. Хотя, на местах возможно все, что угодно.

← →
MsGuns (2003-04-01 11:20) [27]

>stone © (01.04.03 10:44)
>А вообще аналитика и постановка задачи всегда ценятся больше, чем кодирование

Эти б слова да богу в уши ;))
Только на этом форуме вряд ли мы найдем понимание ;(

← →
handra (2003-04-01 12:53) [28]

stone © (01.04.03 10:44)

> А стоимость работы постановщика, к примеру у нас, меньше,
> нежели программиста-технолога

Странное сочетание
> программиста-технолога...
Извините, а кто как не программист с опытом имеет полное понимание технологии?

MsGuns © (01.04.03 11:20)
>stone © (01.04.03 10:44)
>А вообще аналитика и постановка задачи всегда ценятся больше, чем кодирование

Эти б слова да богу в уши ;))
Только на этом форуме вряд ли мы найдем понимание ;(
Увы, до этого не доросли. Возможно в этом форуме одной веткой было бы меньше.

← →
MsGuns (2003-04-01 13:13) [29]

>handra © (01.04.03 12:53)

Не понимаю, чего ты хочешь. Курс лекций по теории автоматизации, реляционным БД и этапам проектирования и разработки ? Тогда непонятно, ты хочешь читать или слушать ? Если читать, то давай, мы внимательно послушаем, если слушать, то слушай и не возмущайся.

← →
handra (2003-04-01 13:27) [30]

MsGuns © (01.04.03 13:13)
handra © (28.03.03 16:00)
Интересует мнение общественности многоуважаемого портала. Как Вы относитесь к означенной теме, если у кого опыт разработки и внедрения. Интересуют мнения, ссылки на материалы и результаты внедрения полных технологических циклов.
Вопрос снят?
Я хочу узнать как у кого это организовано, примерно:
1. Выбор задачи.
2. Проработка предметной области, создание ТЗ (постановщик)
и т.п. вплоть до того, как организовано сопровождение, состав команды разработки (должности и обязанности), время разработки среднего проекта (туманное определение).

Технологии создания ПО Найти похожие ветки