Jump to content

Рабочее


Recommended Posts

Друзья!

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

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

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

Встречный ветер - это не только сопротивление, но и подъемная сила..." (С) Kalter - 72АГ

---

kzvezda_for.jpg10years_for.jpg

 

72AG.gif

Общение в Газете:

72ag_comments.gif

Link to post
Share on other sites

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

начнешь думать - опоздаешь

Link to post
Share on other sites
Скажите - где можно почитать про управление качеством в программировании, в построении сложных программных систем?

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

 

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

 

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

In theory there is no difference between theory and practice. In practice there is.

Link to post
Share on other sites
Скажите - где можно почитать про управление качеством в программировании, в построении сложных программных систем?

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

 

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

 

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

 

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

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

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

Встречный ветер - это не только сопротивление, но и подъемная сила..." (С) Kalter - 72АГ

---

kzvezda_for.jpg10years_for.jpg

 

72AG.gif

Общение в Газете:

72ag_comments.gif

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

 

 

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

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

Встречный ветер - это не только сопротивление, но и подъемная сила..." (С) Kalter - 72АГ

---

kzvezda_for.jpg10years_for.jpg

 

72AG.gif

Общение в Газете:

72ag_comments.gif

Link to post
Share on other sites

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

 

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

 

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

Link to post
Share on other sites

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

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

Мужик:

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

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

Логика и тактика! (С) Би-Зет

kzvezda_for.jpgzazaslugi_for.jpg10years_for.jpg

57

Link to post
Share on other sites
Внедрена методология AIM. Разрабатывается DataWarehouse.

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

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

 

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

In theory there is no difference between theory and practice. In practice there is.

Link to post
Share on other sites
А я думаю, что дело не в программистах.

...

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

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

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

...

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

 

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

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

...

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

 

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

 

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

Встречный ветер - это не только сопротивление, но и подъемная сила..." (С) Kalter - 72АГ

---

kzvezda_for.jpg10years_for.jpg

 

72AG.gif

Общение в Газете:

72ag_comments.gif

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

 

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

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

In theory there is no difference between theory and practice. In practice there is.

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

 

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

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

 

 

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

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

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

 

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

Встречный ветер - это не только сопротивление, но и подъемная сила..." (С) Kalter - 72АГ

---

kzvezda_for.jpg10years_for.jpg

 

72AG.gif

Общение в Газете:

72ag_comments.gif

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

 

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

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

 

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% у вас есть консалтер - подними вопрос, пусть парится. Налаживать процессы - это его задача.

In theory there is no difference between theory and practice. In practice there is.

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

 

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

 

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

 

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

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

Встречный ветер - это не только сопротивление, но и подъемная сила..." (С) Kalter - 72АГ

---

kzvezda_for.jpg10years_for.jpg

 

72AG.gif

Общение в Газете:

72ag_comments.gif

Link to post
Share on other sites
Спасибо. Боже, как же оно тяжело понять :) Мне бы в терминах "по понятиям" :)

 

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

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

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

 

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

 

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

In theory there is no difference between theory and practice. In practice there is.

Link to post
Share on other sites
Есть лишь документ с описанием того, что должно быть. Я не прав?

 

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

 

1. Прав.

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

 

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

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

:)

Встречный ветер - это не только сопротивление, но и подъемная сила..." (С) Kalter - 72АГ

---

kzvezda_for.jpg10years_for.jpg

 

72AG.gif

Общение в Газете:

72ag_comments.gif

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...