Рабочее

[Arrow]

Друзья!

Мои программисты меня достали, косяк за косяком.

Скажите - где можно почитать про управление качеством в программировании, в построении сложных программных систем?

Можно с примерами Success Story.

[paraplanoff]

может, не совсем то, но первым в голову приходит rsdn.ru, раздел Книги, там Проектирование ПО.если что, часть книг оттуда у меня есть. могу кинуть на фтп.например, неплохая книга Ф. Брукс - Мифический человеко-месяц, или как создаются программные системы

[ABC]

Скажите - где можно почитать про управление качеством в программировании, в построении сложных программных систем?

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

 

Что именно интересует, управление качеством понятие уж очень обширное.

 

Так то список литературы можно накидать, но можно работать по площадям, а можно точечно. Кстати, я бы лично советовал начать с Де Марко, Брукс несколько академичен, ИМХО.

[Arrow]

Скажите - где можно почитать про управление качеством в программировании, в построении сложных программных систем?

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

 

Что именно интересует, управление качеством понятие уж очень обширное.

 

Так то список литературы можно накидать, но можно работать по площадям, а можно точечно. Кстати, я бы лично советовал начать с Де Марко, Брукс несколько академичен, ИМХО.

 

Внедрена методология AIM. Разрабатывается DataWarehouse.

Лично у меня функциональное наполнение (MD.050, TE.020) и контроль качества данных.

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

[Arrow]

Кстати, я бы лично советовал начать с Де Марко, Брукс несколько академичен, ИМХО.

 

 

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

И желательно на моем родном языке

[ClearSky]

А я думаю, что дело не в программистах. Я общался с очень грамотными людьми, и код, который они писали, просто великолепен. Но! Даже они бессильны что-либо сделать нормально, если некачественно подготовлены исходные позиции. Если неясны и нечетко сформулированы задачи для программиста. Я имею ввиду техническую и проектную документацию. В первую очередь, в ней в ясной и четкой форме должна быть изложена общая архитектура ИС. Затем вся Система должна быть разложена на Подсистемы и модули. Это деление логическое и чисто условное. Но оно позволяет выделить конкретные функциональные направления. При проектировании ИС в полной мере действует принцип "Разделяй и влавствуй". Понять принцип, разработать алгоритм и затем реализовать его в коде гораздо проще и быстрее для небольшого кусочка ИС, чем сразу попытаться "съесть" ее за раз. По моему мнению, в общем объеме разработки ИС 70% объема выполняемых работ составляет проектирование и составление тех. документации, и только 30% занимает непосредственно кодирование, отладка и внедрение нового кода в рабочую конфигурацию.

 

Скорее всего, ваши программисты "портят" все просто потому, что они не знают и не видят всей архитектуры ИС. Поэтому и получается так, что исправляя конкретную часть системы, они невольно затрагивают остальные. Сам с этим постоянно сталкиваюсь, поэтому и пишу эти слова. Вообще, найти грамотного программиста очень легко. В частности, по 1С. Но вот найти грамотного архитектора или архитектора ИС - во сто крат сложнее! Лично я не слышал, чтобы этому искусству обучали в ВУЗах, поэтому сейчас такие люди - самородки либо самоучки, методом проб и ошибок постигающих эту науку. Но именно эти люди могут держать в своей голове всю ИС, объяснить каждому программисту исходные задачи по его кусочку, проконтролировать качество исполнения каждым программистом его работы и как эта работа укладывается в общую архитектуру Системы. Я думаю, у вас с этим проблема, а не с программистами.

 

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

[Bizet(Би-Зет)]

Нашел мужик кувшин запечатанный. Открыл кувшин, а оттуда джин вылез. Говорит:

- Ты меня освободил, в благодарность я твое желание выполню.

Мужик:

-Хочу себе орган мужской до колен.

Джин подумал, подумал и сделал мужику бёдра по 14 см. Так будем же наконец ставить корректные технические задания программистам!

[ABC]

Внедрена методология AIM. Разрабатывается DataWarehouse.

Лично у меня функциональное наполнение (MD.050, TE.020) и контроль качества данных.

Ораклисты, значит.

 

Ок, посмотрим.

[Arrow]

А я думаю, что дело не в программистах.

...

Если неясны и нечетко сформулированы задачи для программиста. Я имею ввиду техническую и проектную документацию.

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

Затем вся Система должна быть разложена на Подсистемы и модули. Это деление логическое и чисто условное. Но оно позволяет выделить конкретные функциональные направления. При проектировании ИС в полной мере действует принцип "Разделяй и влавствуй". Понять принцип, разработать алгоритм и затем реализовать его в коде гораздо проще и быстрее для небольшого кусочка ИС, чем сразу попытаться "съесть" ее за раз.

...

По моему мнению, в общем объеме разработки ИС 70% объема выполняемых работ составляет проектирование и составление тех. документации, и только 30% занимает непосредственно кодирование, отладка и внедрение нового кода в рабочую конфигурацию.

 

Скорее всего, ваши программисты "портят" все просто потому, что они не знают и не видят всей архитектуры ИС.

Поэтому и получается так, что исправляя конкретную часть системы, они невольно затрагивают остальные. Сам с этим постоянно сталкиваюсь, поэтому и пишу эти слова. Вообще, найти грамотного программиста очень легко. В частности, по 1С. Но вот найти грамотного архитектора или архитектора ИС - во сто крат сложнее! Лично я не слышал, чтобы этому искусству обучали в ВУЗах, поэтому сейчас такие люди - самородки либо самоучки, методом проб и ошибок постигающих эту науку. Но именно эти люди могут держать в своей голове всю ИС, объяснить каждому программисту исходные задачи по его кусочку, проконтролировать качество исполнения каждым программистом его работы

...

и как эта работа укладывается в общую архитектуру Системы. Я думаю, у вас с этим проблема, а не с программистами.

 

Ну, во первых. Согласно методологии AIM - документирование производится в полном объеме. TA - Функциональная архитектура, RD-карточки показателей, MD-разработка показателя, MD ETL - загрузка показателей, TE-тестирование разработок

 

А самое главное - главный "косячник" - архитектор системы

[ABC]

Ну, во первых. Согласно методологии AIM - документирование производится в полном объеме. TA - Функциональная архитектура, RD-карточки показателей, MD-разработка показателя, MD ETL - загрузка показателей, TE-тестирование разработок

 

А самое главное - главный "косячник" - архитектор системы

Как у вас поставлен процесс тестирования? В деталях не обязательно, можно в общем.

[Arrow]

Ну, во первых. Согласно методологии AIM - документирование производится в полном объеме. TA - Функциональная архитектура, RD-карточки показателей, MD-разработка показателя, MD ETL - загрузка показателей, TE-тестирование разработок

 

А самое главное - главный "косячник" - архитектор системы

Как у вас поставлен процесс тестирования? В деталях не обязательно, можно в общем.

 

 

Насколько я понимаю.

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

После разработки проводится тестирование и оформление документа ТЕ - запускаются запросы и сверяются результаты с ожидаемыми. Потом идет недокументированная переписка с разработчиком на тему "почему он сам не проверил, и почему результаты не такие как ожидаются". Потом результаты становятся ожидаемыми - и документ тестирования подписывается.

 

Вот как-то так.

[ABC]

После разработки проводится тестирование и оформление документа ТЕ - запускаются запросы и сверяются результаты с ожидаемыми. Потом идет недокументированная переписка с разработчиком на тему "почему он сам не проверил, и почему результаты не такие как ожидаются". Потом результаты становятся ожидаемыми - и документ тестирования подписывается.

 

Вот как-то так.

Т.е. разработчики коммитят изменения, не прошедшие тестирование? Первым делом ткнуть носом разработчиков в описание их роли, в частности:

 

Developer

The developer understands the requirements from the business analysis

and how to meet these requirements using the Technical Architecture

and Data Model.

....

The developer also produces partition integration test plans and

performs testing of partitions and system. During the various testing

activities and the production phase, this project role diagnoses faults

and determines corrections.

 

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

 

В порядке горького юмора - если вам протолкнули A.I.M., то 100% у вас есть консалтер - подними вопрос, пусть парится. Налаживать процессы - это его задача.

[Arrow]

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

 

В порядке горького юмора - если вам протолкнули A.I.M., то 100% у вас есть консалтер - подними вопрос, пусть парится. Налаживать процессы - это его задача.

 

Спасибо. Боже, как же оно тяжело понять Мне бы в терминах "по понятиям"

 

А с AIM вообще прикол. Сторонняя контора внедряла нам OEBS. И подсадила на методологию. А DataWarehouse - уже собственная разработка на "игле" AIM.

Ну, а со сторонней конторой - "консалтером" уже года полтора расстались, ибо дорого. Теперь все собственным IT-department масштабируем и делаем новые разработки к OEBS, ну и параллельно DWH выращиваем...

[ABC]

Спасибо. Боже, как же оно тяжело понять Мне бы в терминах "по понятиям"

 

А с AIM вообще прикол. Сторонняя контора внедряла нам OEBS. И подсадила на методологию. А DataWarehouse - уже собственная разработка на "игле" AIM.

Ну, а со сторонней конторой - "консалтером" уже года полтора расстались, ибо дорого. Теперь все собственным IT-department масштабируем и делаем новые разработки к OEBS, ну и параллельно DWH выращиваем...

По понятиям - спроси тим-лида разрабов, понимают ли они, что в их обязанности входит первоначальное тестирование и разработка программ, которые проходят тесты, а не заваливают их. QA не должен тратить свое время на тестирование нефункционирующей системы. Если разрабы всё понимают, то в чем проблема спроси - может тесты неверны, или требования размыты слишком. А может среда для тестирования не соответствует предъявляемым требованиям - устарела или что-то еще. Но, почему-то, у меня есть подозрение, что тестовых сценариев и автоматического тестирования у вас нет вообще. Есть лишь документ с описанием того, что должно быть. Я не прав?

 

А вообще, этот вопрос должен ПМ поднять, пусть и по твоей наводке.

 

Что-то почитать, чтобы быстро решить проблему не получится, наверное. Погугли Тома Демарко "Роман об управлении проектами" для начала. В любом случае это мастхэв для всех, связанных с разработкой. Посмотри курсы на intuit.ru, может найдешь себе что-то интересное. Сложно сказать, что подойдет. Я же не знаю твой уровень, и что тебе надо в итоге.

[Arrow]

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

 

А вообще, этот вопрос должен ПМ поднять, пусть и по твоей наводке.

 

1. Прав.

2. Кажется так получилось, что в этом проекте должен кто-то стать ПМ, ибо единый ПМ на весь проект Oracle - и OEBS, и DWH. А в глазах ТОПов это два разных проекта

 

А вообще - большое спасибо за рассказ про "кухню"

И за рассказ - "как это правильно" !