На сайте ведутся работы Контекст "Ошибки в программировании и производительность программиста" | Нематериальное стимулирование, компенсационные пакеты | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Все категории » Нематериальное стимулирование, компенсационные пакеты » Что мешает программистам IT-отделов…

Контекст "Ошибки в программировании и производительность программиста"

Ваши данные (просмотреть)
в избранные темы
Политика конфиденциальности

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
Создать аналогичное обсуждение...

Авторы

Скрыть / Показать
2002-12-03 16:45:00
NKudinov » Всем
Добрый вечер!

Хочу спросить.

Вот в литературе, так или иначе связанной с разработкой программного обеспечения, часто встречается термин "кризис разработки ПО". Под этим понимают то, что проекты не укладываются в срок и бюджет. Почему прошло 30 лет (еще в 70 годы заговорили об этом) и ничего не меняется. Как по-Вашему, что мешает IT-отделам делать качественное программное обеспечение быстро и не превышаю бюджета?
[Показать все ответы на это сообщение]
2002-12-03 22:21:56
Serega » NKudinov

Неправильное планирование :-) Если быть точнее, то всему виной слишком общая постановка задачи. Что бы хоть как-то (+-)10% соблюсти сроки нужно брать в команду не программистов а кодеров, которые переводят в понимаемый компилятором язык то, что написано постановщиком. То есть задание не должно содержать ничего, что требовало бы работы по поиску (разработке) алгоритма реализуемой части. то есть постановка задачи должна быть программой но не на языке программирования.

Да и за время разработки продукта от полугода до N лет (допустим планирование было идеальным и разработчик тоже) меняется среда в которой этой программе нужно работать.

[Нет ответов на это сообщение]
2002-12-10 10:40:04
Сергей В. Сычев » NKudinov

Добрый день! Присоединяясь к уже сказанному выше, добавлю следущее.

Несмотря на "раскрученность", профессия программиста в сравнении с другими инженерными профессиями - младенческая. Многие копья, которые ломаются ныне в soft-среде, в иных отраслях были уже сломаны лет 150 назад, а лет 120 назад заменены на пистолеты.

Например,

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

Как сказал кто-то умный Биллу Гейтсу: "Если бы проектирование и производство автомобилей происходило столь же неаккуратно, как создание программного обеспечения, то автомобили беспричинно "зависали" бы каждый день, а при переключении скоростей глохли бы и предлагали перезапустить двигатель или обратиться в сервис-центр".

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

Вывод: Что-то неизбежно начнет меняться, когда уважаемые программисты начнут избавляться от описанных выше моделей поведения и рекламировать другие ценности.

С искренним уважением,

[Показать все ответы на это сообщение]
2002-12-10 12:56:56
Serega » Сергей В. Сычев

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

Я не стану спорить с уважаемым Сергей В. Сычев, просто хочется сказать, что врядли инженер стал бы под мост, если б он знал, что все кому не лень начнуть строить рядом с мостом какие-то здания и совершенствовать опоры моста, украшать мост лепниной весом в N тонн, сажать на него самолеты и т.д. Прежде чем стать под мост инженер был уверен, что по мосту пройдет именно товарный поезд весом в N тонн. Именно пройдет, а не начнет на нем скакать.

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

Этой репликой я лишь хотел сказать, что отрасль программирования несомнненно продвинулась в сторону качества, если бы срок жизни среды в которой работает программа (ОС, железо, прикладное окружение) остановилось бы в своем развитии хотябы лет на 10.

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

Ну и 10 лет назад "программисты" не занимались поддержкой пользователей и не покупали компьютеры. Просто слишком многих людей стали называть программистами. Словом программист называют ЛЮБОГО кто не набивает на компьютере накладные или договора.

Гарантии всегда даются при определенных условиях. Но они должны даваться и тем более соблюдаться. Прозрачность это неотъемлемая часть качества. (не стоит путать прозрачность с открытостью)

[Показать все ответы на это сообщение]
2002-12-10 13:47:35
Сергей В. Сычев » Serega

День добрый!

>врядли инженер стал бы под мост, если б он знал, что все кому не лень начнуть строить рядом с мостом какие->то здания и совершенствовать опоры моста, украшать мост лепниной весом в N тонн, сажать на него >самолеты и т.д. Прежде чем стать под мост инженер был уверен, что по мосту пройдет именно товарный поезд >весом в N тонн. Именно пройдет, а не начнет на нем скакать.

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

Я же писал о другом. Об отношении к сложным задачам.

Когда мост падает, для инженера - это зачастую личная драма. Даже, если никто не пострадал.

Когда "ломается софт", для многих (увы!) программистов - это "совершенно естественно".

Условно говоря имеем мин. две позиции:

а) "Вот есть сложная система и поэтому (серия примеров и аргументов) я ни за что не хочу ручаться"

     (Позиция 1)

б) "Да, эта система сложна, но я приложу максимум усилий, чтобы она работала стабильно. И в этом (кроме прочего) заключается моя профессиональная гордость".

     (Позиция 2)

Согласитесь, есть разница.

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

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

С Уважением,

[Показать все ответы на это сообщение]
2002-12-10 15:14:55
Serega » Сергей В. Сычев

День добрый!

Когда мост падает, для инженера - это зачастую личная драма. Даже, если никто не пострадал.

и программисты такие есть

Когда "ломается софт", для многих (увы!) программистов - это "совершенно естественно"

и такие наверно есть

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

наплевательское отношение к работе свойственно не только программистам.

Условно говоря имеем мин. две позиции:

а) "Вот есть сложная система и поэтому (серия примеров и аргументов) я ни за что не хочу ручаться"

     (Позиция 1)

он нигде долго не протянет

б) "Да, эта система сложна, но я приложу максимум усилий, чтобы она работала стабильно. И в этом (кроме прочего) заключается моя профессиональная гордость".

     (Позиция 2)

Согласитесь, есть разница.

Естественно есть. Вторая выигрышней не только для программистов.

 

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

Ну да :-) и срок дадут за некачественную работу выразившуюся в растрате понапрасну материальных средств государства. Да я бы сразу уехал из такого государства. При чем тут инженер? Откуда он знал что в районе за N км от моря на обычный мост выльется N тонн морской воды? Выговор - максимальное наказание если оно вообще будет. И было бы странно иное.

В ЛЮБЫХ профессиях есть трудяги и халтурщики, каждый день мы с этим сталкиваемся, но почему-то программистов некоторые люди априори считают халтурщиками. Наверно уже пора проводить среди народа разъяснительную работу, что бы слово "программист" не ассоциировалось у них с мальчиком который к ним подбегает, либо с техником, обслуживающим компьютеры.

[Показать все ответы на это сообщение]
2002-12-10 16:05:35
Сергей В. Сычев » Serega

Еще раз, день добрый!

> вторая выигрышней не только для программистов

>и программисты такие есть

Конечно, и я даже таких знаю :-).

Далее, как мне кажется, для добросовестных программистов профессионально важно активно пропагандировать/рекламировать позицию 2 и "отстраиваться" от тех, кто занимает позицию 1.

(Пока последних, к несчастью, больше и они действительно "портят рынок").

>В ЛЮБЫХ профессиях есть трудяги и халтурщики, каждый день мы с этим сталкиваемся, но почему-то >программистов некоторые люди априори считают халтурщиками (...)

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

>Ну да :-) и срок дадут за некачественную работу выразившуюся в растрате понапрасну материальных средств >государства (...) При чем тут инженер? Откуда он знал что в районе за N км от моря на обычный мост выльется >N тонн морской воды?

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

>Да я бы сразу уехал из такого государства...

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

С пожеланием сильных решений!

[Показать все ответы на это сообщение]
2002-12-10 16:28:53
Serega » Сергей В. Сычев

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

 Даже и не в сейсмозоне, а в обычном городе, если дом будет построен с нарушением соответствующих СНиП'ов - это может очень дорого обойтись.

если жертв нет или даже есть - какая ответственность у инженеров и строителей? примеров масса когда дома построенные ради соблюдения срока или ради набивки карманов на стройматериалах - складывались просто. Ради интереса? Кого и как наказывают среди принимавших участие в строительном проекте? За что можно наказать Васю, который кирпичи таскал, Или Петю который проект делал? А начальство строительное - это надо чтоб пара микрорайонов одновременно рухнула, вот тогда им может строгача и ввалят.

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

Есть программисты которые пишут ПО для спутников и медицинских приборов. Я думаю у них с нормами морали и ответственности наверно порядок. (Хотя слышал один американский спутник таки исчез из-за программера :-) Наверно его оштрафовали :-)

[Показать все ответы на это сообщение]
2002-12-10 17:18:32
Сергей В. Сычев » Serega

Цитата:

> (...) это надо чтоб пара микрорайонов одновременно рухнула, вот

> тогда им может строгача и ввалят.

Это не так.

>(Хотя слышал один американский спутник таки исчез из-за >программера :-) Наверно его оштрафовали :-)

Я думаю это, как раз, одна из баек придуманная для оправдания слабости. По крайней мере, я таких слышал уже штук 7 (про спутник, утонувший корабль, потерявшуюся ракету и т.п.).

Постоянные байки про неудачников не возвышают имидж профессии.

А вот легенды про программера своим решением спасшего (пусть не спутник), но хоть, что-нибудь значимое что-то давно не слыхать. Хотя фактура наверняка есть.

С Уважением,

[Нет ответов на это сообщение]
2002-12-15 01:59:39
Кирилл Лебедев » Всем
По поводу программистов и их отношения к работе согласен с мнением Сергея В. Сычева. У самого на работе есть несколько подобных "коллег".

По поводу технологии работы программистов и причин возникновения ошибок в программах рекомендую статью: http://www.homepc.ru/doityourself/22457/
[Нет ответов на это сообщение]
2002-12-15 21:22:03
roman eremin » Всем

Сравнивая процесс программирования с процессом конструирования моста, я бы хотел отметить одну особенность:

Допустим, строительство моста состоит из следующих фаз:

- Разработка проекта (3 человеко-месяца)

- Сборка конструкции по проекту (40 человеко-месяцев)

Если попытаться найти прямую аналогию, то разработка программы состоит из таких же фаз:

- Разработка проекта (описание того, что надо сделать на языке программирования) (3 человеко-месяца)

- Сборка собственно программы (компиляция) (практически мгновенно).

Отсюда можно сделать два вывода:

1) Сравнивать мост, над которым работали 20 рабочих два месяца надо с программой, которую один программист делает три месяца (это достаточно небольшой проект). Код Windows надо сравнивать не иначе как с конструкциями всех автомобилей за все времена.

2) "Бесплатный" этап сборки ПО дает программистам свободу пробовать свой проект сразу после написания. Оборотной стороной этого является беспечность.

[Нет ответов на это сообщение]
2002-12-16 11:31:02
Виталий Онегов » Всем

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

По поводу плохих и хороших программистов и создания проектов.

Мне кажется, что 50% вины за несвоевременно или неправильно сделанный проект, который к тому же не уложился в бюджет - это вина начальства фирмы, для которой это все делается. Почему? Да потому, что обычно хочется много всего за небольшие деньги и быстро. А по мере продвижения проекта вдруг оказывается, что много-много чего не предусмотрели, забыли, придумали - вот она, дополнительная функциональность, переделка уже сделанного и т.д. и т.п. Опять же, за небольшие деньги кого наймешь? Правильно, программистов из пункта 1 (см. выше). На пункт 2 не хватает маней :) Результат следует очевидный - если чего и сделано, то ужас как.

Это конечно все в кратце.......

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

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

И по поводу ответственности за сделанное: стоит взглянуть на технику, бытовую или какую другую, сделанную в России, то возникает мысль: если инженер должен нести ответственность за все это, то вся российская промышленность останется без инженеров и т.п. - потому что за ЭТО казнить надо, а не выговоры делать. Но раз все на месте - значит ответственность никто не несет :)

Извиняюсь за сумбурность, что-то сегодня мысли вперемешку ходят :))

[Показать все ответы на это сообщение]
2002-12-16 12:05:00
GMN » Виталий Онегов

Дискуссия как-то перерастает в полемику... Программы... мосты... Я не видел ни одной умной и удобной конструкции компостера в траспорте. Можно подумать что их разрабатывали на основе нескольких железяк, хлама и деталей, случайно найденных при уборке в кладовой. Хотелось бы понадеяться, что рынок выберет для своего будущего людей, которые будут делать вещи добротно и добросовестно "как для себя", а не "лишь бы клацало", ... и немного воодушевить: Низкоуровневое программирование осталось только как узкое направление, а недалёк день, когда наработанный опыт станет основой уже даже не визуального, а постановочного программирования, когда сама среда разработки станет программистом, а сам разработчик только идейным вдохновителем и руководителем. Художник, разговаривающий с кистью и мольбертом.

PS ... тогда и Кирилл Лебедев сменит адрес с лекарства от головной боли askofen@mail.ru на более жизнерадостный типа шампанского@malo.ru
[Нет ответов на это сообщение]
2002-12-16 12:27:14
Vladimir Kirichenko » Сергей В. Сычев
Доброго!

Ответственность за рухнувший мост несет иманно "Проектировщик". А не Вася, который бетон лопатой мешал.

Вы же сами говорите о модели Архитектор-Кодеры, и сами же говорите, что ответсвенность должны нести программисты.

Васю который бетон лопатой мешал никто не обвинит в том, что мост рухнул. Следовательно в случае модели Архитектор-Кодеры только архитектор виноват. А обвинить вы в данном случае хотите всех. Так вот за такую ответственонсть надо платить адекватное вознаграждение. Нельзя требовать от программиста, который получает ооочень маленькие деньги относительно стоимости проекта, чтобы он отвечал за провал проекта. Нельзя требовать от конторы, которая выполняла реализацию билинга мобильного провайдера и получила фиксированную оплату ответственности за убытки в случае, если билинг глюконет. Единственный справедливый контракт подобного рода это контракт, который дает право участия в прибыли. А это уже очень другие деньги. Ответственность покупаеться за очень другие деньги. А на это ни один заказчик не пойдет. Так вот пока все заказыветься по дешевке - получаеться соответствующее качество. Пока заказчик хочет все(хотя обьяснить что именно не может), по быстрому, и за дешево - он будет получать соответствующее качество. А поскольку кушать всем хочеться - ему будут предоставлять свои услуги по реализацию c этими условиями. Это реальность.
[Показать все ответы на это сообщение]
2002-12-17 13:49:51
Сергей В. Сычев » Vladimir Kirichenko

Да, я согласен с тем доводом, что при разделении функций "Архитектор - Кодер" большая ответственность (в определенных случаях, вся) ложится на "архитектора".

Правда, я бы эту цепочку изложил чуть иначе: "Архитектор - Технолог - Кодер", либо "Архитектор - Технолог - Кодер - Контролер" (думаю лет через 7 такая модель станет привычной). То есть, программирование в своем развитии те же этапы, что и другие специальности.

Я также внимательно перечитал свои сообщения и не обнаружил там "желания обвинить всех", да и вообще желания "обвинить".

Я просто изложил факты:

Факт 1: "Ошибок в программном обеспечении очень много"

Факт 2: "Есть разделяемая многими (но не всеми) "теория" о том, что наличие ошибок это нормально. Эта "теория" временная.

Факт 3: "Есть альтернативная точка зрения. И она более продуктивна".

Факт 4: "В иных отраслях аналогичные споры уже были.

Например, в медицине спор о качестве качестве работы врача и о его ответственности был актуален в 1820-30-е годы. (При этом, я хотел бы обратить Ваше внимание на тот факт, что не только весь организм человека, но большинство органов - это более сложные и по сей день менее понятные системы, чем Windows). В начале 19 века считалось, что "раз человек так сложен", то, когда он умирает в больнице - это совершенно нормально. Если выжил - это победа врача, если умер - так угодно богу. См., например, статью "Победа для побежденных".

С Уважением,

[Показать все ответы на это сообщение]
2002-12-17 13:55:13
Сергей В. Сычев » Всем

На мой взгляд, пусть частичные, но продуктивные ответы дал Кирилл Лебедев:

С Уважением,

[Нет ответов на это сообщение]
2002-12-17 15:14:38
Grigoriev Alexey » Сергей В. Сычев
>> В начале 19 века считалось, что "раз человек так сложен", то, когда он умирает в больнице - это совершенно нормально. Если выжил - это победа врача, если умер - так угодно богу.

А сейчас что-то изменилось?
Смертность на этой плнете все-еще 100%.
[Показать все ответы на это сообщение]
2002-12-17 20:43:43
therapy.narod.ru » Grigoriev Alexey
Изменилось. Ведь нужно говорить не о смертности, а о продолжительности жизни. Однополое существо смертно по своей сути. Вот продолжительность жизни намного выросла, вспомните, что несколько тысяч лет назад средняя продолжительность жизни была 30-40 лет, сейчас в Японии - 80 лет. Лишние сорок лет по моемому неплохой шаг для медицины. А болезни, которые не считаются больше смертельными: чума, например; а хирургия: сегодня Пушкин бы не умер от раны в живот, и много других примеров. Дело в том, что человек сам не хочет жить дольше, ведь вы даже не знаете, как предупредить развитие сердечно-сосудистой патологии, так как именно она стоит на первом месте по причине смертности.
[Показать все ответы на это сообщение]
2002-12-17 22:05:09
Кирилл Лебедев » Vladimir Kirichenko
> Ответственность за рухнувший мост несет иманно
>"Проектировщик". А не Вася, который бетон лопатой мешал.
> Вы же сами говорите о модели Архитектор-Кодеры, и сами же
> говорите, что ответсвенность должны нести программисты.

Мне кажется, ответственность должны нести все: и Архитектор системы, и продюсер, и мэнеджеры, и программисты. А то получается, как всегда, - перекидывание ответственности друг на друга.
Если каждый из этой цепочки "Архитектор - продюссер - мэнеджер - программист" научится брать ответственность на себя, а не перекладывать ее на других, качество программных продуктов, по моему мнению, возрастет.
[Показать все ответы на это сообщение]
2002-12-18 10:50:42
Grigoriev Alexey » Кирилл Лебедев
>>сли каждый из этой цепочки "Архитектор - продюссер - мэнеджер - программист" научится брать ответственность на себя..........

Вот поэтому, так все и работает. QA - даже не предусмотрен, а ведь, отвественный за QA - и есть _самый главный виноватый_ по ВСЕМ вопросам качества.
[Нет ответов на это сообщение]
2002-12-18 15:49:45
Георгий Соколов » Всем
Уважаемые коллеги!
 
Профессия программист болеет рядом болезней, свойственных:
а) молодым профессиям
(сверхреклама возможностей, низкое в среднем качество, отсутствие понятных критериев оценки и контроля качества и т.п.)
б) творческим профессиям
(завышенная самооценка, привычка постоянно "шаманить", сопротивление любой "технологизации" процесса работы и т.п.)
 
Программистам было бы полезно посмотреть на ситуацию "со стороны". Например, как схожие проблемы во взаимоотношениях между Заказчиками и Исполнителями возникали и продолжают возникать: 
- в рекламной деятельности:
"Бранятся или тешатся? Взаимопретензии рекламодателей и рекламистов" (проанализирован опыт Коллег из более чем 20 городов);
- в выставочной деятельности:
 
С уважением,
Георгий Соколов
(программист)
[Нет ответов на это сообщение]
2002-12-18 16:00:23
Александр » Сергей В. Сычев

Добрый день, Сергей!

> Вопросы качества проекта для инженеров (не программистов) -

> это давно вопросы чести. Инженер -строитель после возведения

> моста по его проекту становится под мост и по мосту едет

> товарный поезд

Честно говоря, ни разу не слышал о таком в наши дни, а только читал в исторических книгах. Но допустим, что это так.

> а средне-статистический программист утверждает: "Техника

> сложна. Ошибки всегда будут. За работоспособность программы

> (мной же написанной) я отвечать не хочу".

За работоспособность программы в целом программист как раз отвечает. Если не своей честью, то как минимум своей зарплатой. Но только за работоспособность в целом - большую часть времени и/или в большинстве случаев.

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

Ближайшая аналогий - производство лекарств. Новые препараты тщательно тестируют, проверяют и перепроверяют по 3-5-7 лет (сравните со сроками тестирования средней программы!!!), и всё равно - из 100,000 человек, выпивших лекарство, на 99900 человек оно действует, как было запланировано, на 90 не действует вообще, а 10 попадают в больницу из-за побочных эффектов.

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

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

Ну и, наконец, добавлю, что архитектор не несёт ответственность за ситуации, когда его мост обрушился, скажем, из-за того, что в него врезался "Боинг" или его взорвали партизаны. Программистам же постоянно морочат голову тем, что его программа сбоит, даже если на самом деле сбоит операционная система, связь, железо или что-то ещё. Что делать - пользователь в момент аварии нажимал кнопку именно в этой программе.

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

> Простая фраза "Писать программы без брака" - сегодня могла

> бы стать миссией для любой софт-фирмы).

Если бы была выполнимой.

> И еще. Если лет 10 назад слово "программист" у большинства

> руководителей компаний вызывало стереотип "кого-то очень

> умного и непостижимого, творящего великие программные

> продукты", то сейчас все чаще и чаще стереотип "кого-то очень

> понятного, ленивого, вечно увольняющегося, не доделывающего

> проект, ворующего по мелкому комплектующие и получающего

> чаевые в компьютерных фирмах".

Таких просто не надо брать на работу. Радикальное такое лекарство :)

[Показать все ответы на это сообщение]
2002-12-18 18:32:24
Игорь Грешник » Александр

Уважаемый Александр!

>И если мост должен выполнять одну-единственную операцию стоять...

а) Данная функция сформулирована Вами неверно.

б) Мост выполняет несколько сотен функций.

в) Пароход (тем более, самолет) спроектировать и построить труднее, чем написать большую часть программ, написанных человечеством за последний год.

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

Вы в своем сообщении делаете ряд длинных выводов, основываясь на ошибочных тезисах (некоторые из них выше).

>Возникает такое количество комбинаций, которое человек просто не может охватить умом...

О том, что нельзя "объять необъятное" написал еще не-программист Козьма Прутков. Как раз, в попытке "охватить умом" и заключается одна из надсистемных ошибок, приводящая к ошибкам последующим... Эта ошибка носит название "нетехнологичная работа".

>Честно говоря, ни разу не слышал о таком в наши дни, а только

>читал в исторических книгах...

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

Вообще есть еще много чего такого о чем Вы не слышали.  Всех благ,

[Показать все ответы на это сообщение]
2002-12-18 18:51:44
Михаил Опанасенко » Александр

Александр!

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

Но речь ведь идет о другом.

Я очень согласен с Сергеем Сычевым, который написал: "(...) имеем мин. две позиции:

а) "Вот есть сложная система и поэтому (серия примеров и аргументов) я ни за что не хочу ручаться"

     (Позиция 1)

б) "Да, эта система сложна, но я приложу максимум усилий, чтобы она работала стабильно. И в этом (кроме прочего) заключается моя профессиональная гордость".

     (Позиция 2)

Эти две позиции мы имеем и в данном обсуждении: есть коллеги, которые отстаивают Позицию 1. В частности, Ваша серия примеров и аргументов направлена на ее защиту.

А есть коллеги, которые защищают Позицию 2. Есть даже коллеги, которые не только защищают эту Позицию, но и разрабатывают методику "по сокращению ошибок" (например, Кирилл Лебедев). И кредит доверия к таким коллегам гораздо выше

>> Простая фраза "Писать программы без брака" - сегодня могла
>> бы стать миссией для любой софт-фирмы).

>Если бы была выполнимой

Мне кажется коллегам, которые поддерживают Позицию 2 полезно было бы подумать над работой, которую можно было бы назвать (условно): "Работа над ошибками". Можно ведь сколько угодно спорить о сложности мира, а можно решать задачи.

>Таких просто не надо брать на работу. Радикальное такое лекарство :)

Не надо менять тезис. Речь шла о том, что имидж профессии "программист" снижается. Это, к сожалению, имеет место быть.

С уважением,

[Показать все ответы на это сообщение]
2002-12-18 18:58:04
Редакция » Всем

Редакция присоединяется к позиции Георгия Соколова, а также благодарит Михаила Опанасенко за призыв к "Работе над ошибками".

С Уважением,

[Нет ответов на это сообщение]
2002-12-19 14:00:59
Vladimir Kirichenko » Кирилл Лебедев
Есть и оборотная сторона медали.
Моя ответственность только за то, что находиться в области моего влияния. Как Вася может себя обвинять в том, что мост рухнул из-за слишком тяжелого поезда если:
1. Он не регулирует движением поездов.
2. Не вел рассчеты моста.
3. Вообще ничего не делал кроме ответсвенной работы замешивания бетона?

То же самое и в программировании. За архитектуру он не отвечает, железом не управляет на которой будет работать, зачастую слабо влияет на способ, объем и время реализации. Сказали deadline во вторник - что хочешь делай, а deadline во вторник. Часто реализует не так как думает правильно, но так как сказали сделать.

В таких условиях работы - это чистая блоготворительность со стороны Васи брать на себя какую-то там еще ответсвенность за фиксированнное вознаграждение.
[Показать все ответы на это сообщение]
2002-12-19 14:14:07
Vladimir Kirichenko » Игорь Грешник
> Многофакторность даже при производстве полиэтиленового пакета превышает на несколько порядков число комбинаций, которые нормальный технолог может удержать в голове.

Тогда так - если сравнисть скорость изменения и развития технологий при производстве полиэтиленового пакета(строительстве моста) и в программной сфере - где быстрее и на сколько порядков?

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

Программист выходящий из университета даже не слышал об 99% существующих технологий не говоря о том сколько он знает. И не может себе позволить годик-два поизучать технологию и сказать - я владею ей в совершенстве, и сделаю все правильно. Потому что он уже отстал. Вот и делается все так:
- Знаешь что это?
- Да вот тут пробоал, вчера купил книжку еще....
- Сможешь?
- Ну можно попробовать...
- Делай.

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

[Нет ответов на это сообщение]
2002-12-19 14:49:12
Александр » Михаил Опанасенко

> Вы описали "аварийные взаимоотношения с Заказчиком", который

> меняет правила во время игры.

В той или иной степени это происходит с каждым существенным проектом в области ПО.

>Я очень согласен с Сергеем Сычевым, который написал: "(...)

>имеем мин. две позиции:

>(Позиция 1)

>а) "Вот есть сложная система и поэтому (серия примеров и

>аргументов) я ни за что не хочу ручаться"

>(Позиция 2)

>б) "Да, эта система сложна, но я приложу максимум усилий, чтобы

>она работала стабильно. И в этом (кроме прочего) заключается

>моя профессиональная гордость"

Проблема в том, что второге не исключает первого. Да, разработчик приложил максимум усилий, да, его профессиональная гордость заключается в том, чтобы система работала "на ять" - но при этом он не может гарантировать, что программа не будет сбоить никогда, как разработчик лекарства не может гарантировать, что оно не повредит здоровью ни одного пациента. И тот, и другой может только назначить себе меру ответственности за каждый сбой.

Покажите мне хоть одну серьёзную программу, которая никогда не сбоит - и я встану на Вашу сторону. А до тех пор - увы.

>Не надо менять тезис. Речь шла о том, что имидж профессии

>"программист" снижается. Это, к сожалению, имеет место быть

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

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

Снижение имиджа в таких условиях предсказуемо и неизбежно. И вовсе не из-за качества работы.

[Нет ответов на это сообщение]
2002-12-19 15:21:31
Александр » Игорь Грешник

>б) Мост выполняет несколько сотен функций.

Приведите хотя бы 5, пожалуйста.

>в) Пароход (тем более, самолет) спроектировать и

>построить труднее, чем написать большую часть

>программ, написанных человечеством за последний

>год.

За последний год едва ли написана хоть одна сложная программа. Действительно сложные программные комплексы разрабатываются годами.

[Нет ответов на это сообщение]
2002-12-19 15:26:09
Александр » Vladimir Kirichenko

>Моя ответственность только за то, что находиться

>в области моего влияния. Как Вася может себя обвинять

>в том, что мост рухнул из-за слишком тяжелого поезда

>если:

>
>1. Он не регулирует движением поездов.
>2. Не вел рассчеты моста.
>3. Вообще ничего не делал кроме ответственной работы замешивания бетона?

Добавлю ещё 4-й пункт: не имеет никакого влияния на то, из чего этот бетон состоит - то ли из цемента с песком, то ли из гипса с пенопластом, то ли из манной каши с изюмом. Потому что компиляторы и "компоненты третьей стороны" делались кем-то другим и за их поведение программист тоже отвечать не может.

[Нет ответов на это сообщение]
2002-12-19 16:12:33
Кирилл » Всем
Добрый день всем!
В качестве еще одной мысли по поводу системы обеспечения качества разрабатываемого под заказ ПО могу предложить подумать еще в таком направлении: если уж приводить примеры из области строительства, то надо приводить их полностью. Дело в том, что уважающий себя стройзаказчик (ну или компания, выполняющая функции управления строительными подрядами) имеет или должна иметь в своей структуре подразделение по обеспечению качества, которое контролирует в том числе качество выполненной проектной документации. Могу описать как это происходит, т.к. сам все это наблюдал воочию:
1. Компания-заказчик получает пакет рабочей документации (около 1000 листов чертежей, схем, узлов + сотни листов спецификаций)
2. В течении нескольких недель они рассматривают этот пакет.
3. Присылают список замечаний по пакету документации, в котором указаны: номер замечания, шифр и номер листа чертежа, категория замечания (критично/не критично), фамилия автора замечания/содержание замечания.
Т.е. определенный штат сотрудников методично смотрит каждый листок проекта (а их около 1000) и делает замечания каждый по своему разделу. Один специалист, например, просто читает номера ГОСТов и если они уже отменены или устарели, то пишет замечание.
Так вот собственно, что хотелось сказать: задача обеспечения качества ПО, писанного под заказ является (должна являться) ОБЩЕЙ для обеих сторон и для заказчика и для разработчика. И усилия и материальные средства должны с обеих сторон выделяться (представьте, сколько тратит строительная компания, платя в течении нескольких недель штату специалистов за проверку).
Да, забыл упомянуть одну деталь: счет на оплату услуг проектной организации утверждается только после устранения ВСЕХ замечаний из списка. Это сильный стимул подумать об обеспечении качества с самого начала на этапе разработки (список замечаний получется короче и счет утвердят быстрее).
[Нет ответов на это сообщение]
2002-12-23 01:00:44
Кирилл Лебедев » Vladimir Kirichenko
> Моя ответственность только за то, что находиться в области моего влияния.

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

> Сказали deadline во вторник - что хочешь делай, а deadline во вторник. > Часто реализует не так как думает правильно, но так как сказали сделать.

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

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

Существует 2 подхода:
1. Дайте мне больше ресурсов (времени, денег), и я вам напишу качественную программу.
2. Я умею писать программы вот такого высокого качества. Если вас это заинтересует, то мне для работы нужны такие-то и такие-то ресурсы.

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

P.S. Для тех, кому интересно. Вышла новая статья по ошибкам в программах: http://www.homepc.ru/school/22854/
[Показать все ответы на это сообщение]
2002-12-23 12:27:50
Виталий Онегов » Кирилл Лебедев

>Разумно. Но бывает, что области влияния программиста на программу хватает, чтобы исправить некоторые конструктивные недостатки. Поэтому часто полезно себя спрашивать: "Все ли я сделал для того, чтобы предотвратить этот недостаток?"

Дык получается, что я еще и должен искать какие-то другие недостатки за других людей? Ну, загнул ты, батенька, тут бы свое понять :)


>Программисту приходится работать в противоречивых условиях: с одной стороны давлеют требования качества, с другой - ограничения по времени. Но я замечал, что наиболее качественные решения появляются именно тогда, когда соблюдается как первое, так и второе решения. Как говорится: "Необходимость обостряет разум".

А может все же правильнее вот это высказывание: Спешка важно только при ловле блох ?

>Существует 2 подхода:
>1. Дайте мне больше ресурсов (времени, денег), и я вам напишу качественную программу.
>2. Я умею писать программы вот такого высокого качества. Если вас это заинтересует, то мне для работы нужны такие-то и такие-то ресурсы.

>Второй подход, на мой взгляд, эффективнее, т.к. он не является голословным.

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

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

Так что с кем спорите по поводу надуманных подходов - хотя никто тут за первый не ратовал - я чего-то не пойму

[Показать все ответы на это сообщение]
2002-12-23 13:34:20
Vladimir Kirichenko » Кирилл Лебедев
> Но я замечал, что наиболее качественные решения появляются именно тогда, когда соблюдается как первое, так и второе решения. Как говорится: "Необходимость обостряет разум".

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

> Существует 2 подхода:
> 1. Дайте мне больше ресурсов (времени, денег), и я вам напишу качественную программу.
> 2. Я умею писать программы вот такого высокого качества. Если вас это заинтересует, то мне для работы нужны такие-то и такие-то ресурсы.

> Второй подход, на мой взгляд, эффективнее, т.к. он не является голословным.

На что следует незамедлительный ответ, что это слишком дорого у меня нет столько времени,а в соседней конторе мне напишут дешевле и вовремя, почему вы думаете что вы такие уникальные? Я обращусь к соседу.

И не важно, что в плане качества и денег он не выиграет а может и вообще обламаться с проектом. Важно что колличество денег и времени величины неподконтрольные исполнителям и не бесконечные. А в условиях наличия большого колличества контор выигрывает тот кто предложит самое дешевое и быстрое решение. И если по счастливой случайности проект не загибается - клиенты начинают думать, что реалисты - это люди желающие их ограбить.
[Показать все ответы на это сообщение]
2002-12-24 13:53:49
dkstranger » Vladimir Kirichenko

Предлагаю сформулировать принципы на базе которой можно

прийти к соглашению

  1. В каждом деле существуют сложные проекты,

     существуют задачи, охватить которые человек

     не в состоянии

  2. В области разработки ПО есть специфика, связанная с

     со скоростью модификации как постановки задачи, так и

     со временем реализации

  3. Каждый серьезный профессионал должен нести отвественность

     (в т.ч. моральную) за качество своей работы

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

  5. Разработчик должен стремиться к ликвидации ошибок,

      как своих, так и не зависящих от него

  6. Одним из путей уменьшения числа ошибок является

      создание и развитие специальных, технологий,

      повышающих надежность и качество разработки.

  Думаю, эти пункты не вызовут возражений у участников форума

[Нет ответов на это сообщение]
2002-12-25 00:37:04
Кирилл Лебедев » Виталий Онегов
> Дык получается, что я еще и должен искать какие-то другие недостатки за других людей?

Расширение зоны своей персональной ответственности - хороший прием для профессионального и карьерного роста.

> А может все же правильнее вот это высказывание: Спешка важно только при ловле блох ?

Согласно моей практике, спешка возникает не из-за через чур сильных ограничений по времени, а из-за нетехнологичности процесса разработки ПО.

> Так что с кем спорите по поводу надуманных подходов - хотя никто тут за первый не ратовал - я чего-то не пойму

К сожалению, уважаемые коллеги при обсуждении проблемы нехватки времени перекладывают ответственность на заказчика и вышестоящее начальство и не задаются вопросом: "Что неправильно в моих действиях, что мне приходится работать вечерами и по выходным?"
[Нет ответов на это сообщение]
2002-12-25 00:49:23
Кирилл Лебедев » Vladimir Kirichenko
> ... а так же продлевает рабочий день, плавно переходящий в рабочие выходные и рабочие ночи

Согласно моей практике такое происходит не из-за слишком сжатых сроков разработки ПО, а из-за нетехнологичности процесса разработки.
Например, при работе над последним проектом я потратил:
1) 10 - 15 % времени только из-за отсутствия должной коммуникации с одним из программистов "команды". Поскольку ни одна моя попытка не позволила установить с ним контакт, мне пришлось разбираться в его коде самому. Самому находить его баги. И предпринимать не всегда верные шаги. Он мог потратить час на объяснение. И ничего бы не потребовалось.
2) 20 - 30 % времени мне пришлось потратить на поиск нужной информации, ее изучение и отсев ненужной. В том числе - не только в Интернете, но и внутри компании. Если бы в фирме был организован информационный портал, в котором бы излагался и предыдущий опыт, мои затраты значительно бы сократились.
3) 20 - 30 % времени было потрачено из-за отсутствия технологии решения задач. Часто приходилось перебирать варианты, пытаться решить проблемы, которые не только не имели решения, но и которые-то решать не нужно было.

Итого: достаточно серьезные резервы для оптимизации по времени процесса разработки ПО.

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

Проблема не в дешевизне проекта, а в нетехнологичности процесса получения заказа.
[Показать все ответы на это сообщение]
2002-12-25 13:24:03
Сергей В. Сычев » Кирилл Лебедев

Уважаемый Кирилл! Благодарю Вас за конкретные предложения по устранению ряда ошибок (пока Вы единственный из участников обсуждения, кто это сделал).

Буду рад, если Вам поможет (для развития методики по сокращению ошибок программирования) предложение ввести понятие "уровни ошибок". Я приведу примеры, а потом поясню зачем.

4 уровня ошибок (не настаиваю именно на таком разделении, но мне важен пример).

Уровень 1. Ошибки, причиной которых является простая неаккуратность, неорганизованность...

Примеров множество в любой отрасли.

Уровень 2. Например, такие ошибки, которые описаны в Ваших статьях:

http://www.homepc.ru/doityourself/22457/
http://www.homepc.ru/doityourself/22598/
http://www.homepc.ru/doityourself/22697/
http://www.homepc.ru/school/22854/

Ваш Пример. "Ступенчатый метод" (или слишком длинная цепочка делегирования)

Аналоги за пределами программирования: в любой технологии слишком длинная цепочка делегирований приводит к ошибкам. Так многие инженеры, уже построив рабочий техпроцесс, затем пытаются провести его "свертывание" (то есть, создать модель, когда те же функции выполняются меньшим числом операций). Причем обычно рекомендуется это делать независимо от того обнаружены ли уже ошибки в базовом процессе или нет, ибо при длинной технологической цепочке они всегда вероятны.

Ваш Пример. Перенос части кода из одного фрагмента в другой. Создание нового документа/кода на основе копии старого.

Аналоги за пределами программирования. Их множество. Вот простейший: делопроизводитель создает договор на основе другого договора и создает ошибки. Затем данные ошибки тиражируются, если на основании этих документов, создаются вторичные документы. Скажем в договоре в силу подобного "переноса" образовалась ошибка в реквизитах, как следствие: создали платежку с неверными реквизитами и отправили деньги на другой счет. И т.п.

Ваш Пример. Вынесение типового кода в библиотеку и последующие перенос в др. надсистему без учета ее контекста.

Аналоги за пределами программирования: один и тот же активный металл, соединившись с кислородом даст мел, а с галогеном - соль. Слово не равно "сумме букв", а текст "сумме слов".

Еще пример. Здесь на Форуме Георгий Соколов цитировал своего преподавателя по мат. лингвистике профессора Тузова: "В русском языке "разбить" можно: сквер, палатку, вазу и морду".

Любое "понятие", "вещество", "типовой код" и т.д. при смене контекста может изменить не только свой смысл, но и свою функцию, состояние, свойства и т.д.

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

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

Уровень 3. Ошибки архитектуры (т.е., заложенные при проектировании) и/или неучет технологии

Например,

3.1. Просто нерациональность архитектуры

3.2. Неучет масштаба проекта при проектировании. Или на малом числе операций, записей в базе и т.д. все работает нормально, а на большом - нет.

3.3. Неучет "возрастания разнородности" многочисленных объектов, запросов, взаимодействий при увеличении проекта.

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

3.5. ..... и т.д. ....

3.N. Иное

Уровень 4. Ошибки, возникающие из-за нерешенности действительно серьезных, многофакторных, масштабных задач; задач, содержащих противоречия, с которыми еще не справились в целом по отрасли (то есть, те случаи, на которые ссылаются участники обсуждения, защищая тезис о невыполнимости миссии "писать без ошибок").

Скорее всего, говоря о 4-м уровне, мы, в ряде случаев, уже должны не использовать слово "ошибка", а должны использовать слово "задача".

----------------------------------------------------

Вероятно, можно исправить/изменить предложенную модель (скорее всего, это и надо сделать), а также привести и другие примеры ошибок каждого уровня. Именно, на предложенной схеме я НЕ настаиваю.

Более важны:

А. Само разделение всех разнообразных ошибок по разным "весовым" качественным уровням.
В. Учет того обстоятельства, что (предположительно) профилактические средства от ошибок на каждом уровни будут свои.

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

Эта статистика за годы работы (подчеркну с разными проектами, и с разными программистами) свидетельствует: не менее 80% всех ошибок - это ошибки первого и второго уровней. Ошибки третьего уровня составляют не более 20%, а уж ошибки/задачи 4-го уровня - это вообще "штучный товар". (Даже за корректную формулировку подобных сверхзадач (не то, что за их решение) у нас можно получить премию).

И в таком контексте качественно меняется смысл разговора про выполнимость или невыполнимость миссии "писать без ошибок".

Аналогия за пределами программирования:

"В середине XIX века в Европе при родах от родильной лихорадки умирало не менее 20% рожениц. (А в иных клиниках эта цифра доходила до 50%). К сожалению, большинство врачей считало это вполне нормальным явлением. По их мнению, женщины погибали от «атмосферно-космической» эпидемии, вызываемой невидимыми «миазмами», борьба с которыми совершенно безнадежна. Разумеется, не было недостатка в разговорах о до конца непостижимой сложности организма и многофакторности, которую
умом не охватить и т.д., и т.п.".

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

В знак протеста "обиженные" врачи упекли Земмельвейса в сумасшедший дом.

Однако, в тех клиниках, где это стали делать смертность действительно упала (с 20-ти до 2-х %) и впоследствие этот метод стал общепринятым и, как мы знаем, не только в роддоме.

Еще раз позвольте поблагодарить Вас полезную информацию.

С Уважением,

[Показать все ответы на это сообщение]
2002-12-25 13:54:56
TBB » Кирилл Лебедев

Согласно моей практике такое происходит не из-за слишком сжатых сроков разработки ПО, а из-за нетехнологичности процесса разработки.
Например, при работе над последним проектом я потратил:
1) 10 - 15 % времени только из-за отсутствия должной коммуникации с одним из программистов "команды". Поскольку ни одна моя попытка не позволила установить с ним контакт, мне пришлось разбираться в его коде самому. Самому находить его баги. И предпринимать не всегда верные шаги. Он мог потратить час на объяснение. И ничего бы не потребовалось.

 

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


2) 20 - 30 % времени мне пришлось потратить на поиск нужной информации, ее изучение и отсев ненужной. В том числе - не только в Интернете, но и внутри компании. Если бы в фирме был организован информационный портал, в котором бы излагался и предыдущий опыт, мои затраты значительно бы сократились.

Т.е. кто-то должен сначала потратить время, чтобы популяризовать проделанное командой программистов? :) Нет проблем и есть такие дяди, и есть их книги с прилагаемыми к ним носителями информации... Платите и пользуйтесь на здоровье. ;)

Может лучше обернуться на соседние фирмы, создающие (в отличии от вашей) библиотеки, DLL, и др. коды, предназначенные для повторного использования внутри (как минимум) той же фирмы.


3) 20 - 30 % времени было потрачено из-за отсутствия технологии решения задач. Часто приходилось перебирать варианты, пытаться решить проблемы, которые не только не имели решения, но и которые-то решать не нужно было.

Здесь вообще запутали две темы: отсутствие технологии и решение посторонних проблем. IMHO здесь близко проходит только один вопрос: корректная постановка задачи.


Итого: достаточно серьезные резервы для оптимизации по времени процесса разработки ПО.

Итого: резерва не видно, есть только рекомендация перед тем как приступить к собственно программированию следует разобраться в ТЗ.

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

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

Отчего же. "Дешевые" (в обсуждаемых здесь терминах) коллективы программистов перехватывают заказ (составляют смету) еще до построения ТЗ...

Такая вот диалектика.

;)

[Показать все ответы на это сообщение]
2002-12-25 14:18:21
Редакция » Всем

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

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

[Нет ответов на это сообщение]
2002-12-25 15:08:24
Георгий Соколов » Всем

Уважаемые коллеги!

1) Справедливость требует признать, что часто действительно, как Пишет Кирилл Лебедев "Проблема не в дешевизне проекта, а в нетехнологичности процесса...".

2) О том, как люди обваливают работу - рассказано здесь:                                        

 
3) Как люди САМооправдывают свои ошибки - рассказано в системе Help рабочей версии программы "Приемы журналистки & PR".

Успехов!

[Нет ответов на это сообщение]
2002-12-26 15:20:45
NKudinov » Всем
Про возраст программирования

На мой взгляд дела в космонавтике, радиоэлектронике обстоят намного лучше . Хотя старше они не на много.
Следовательно дело не в возрасте.

Про строителей и программистов

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

Для контролера архитектора
1)Проверить на соотвтетствие требованиям заказчика
2)Проверить на физическую непротиворечивость (законы физики должны соблюдаться)
Для контролера аналитика
1)Проверить на соответствие требования заказчика.

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

И еще если пунк 2 можно проверить в принцыпе автоматически ( с помощью соответвующего ПО).

Итог.
1)Есть и другие младенческие профессии ( по сравнению с строительством)
2)Все проблемы в программировании из-за отсутствия законов программирования.


[Показать все ответы на это сообщение]
2002-12-27 00:19:05
Кирилл Лебедев » Сергей В. Сычев
Благодарю Вас за идею распределить ошибки по уровням. Она помогла мне увидеть и добавить в картотеку некоторые ошибки 3-го уровня (согласно Вашей классификации) и, надеюсь, поможет в поиске ошибок 4-го уровня.

> Учет того обстоятельства, что (предположительно) профилактические средства от ошибок на каждом уровни будут свои.

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

С уважением, Кирилл
____________________

P.S. Некоторые ошибки первого уровня и средства их профилактики описаны в статье: http://www.homepc.ru/school/23000/
[Показать все ответы на это сообщение]
2002-12-27 00:29:53
Кирилл Лебедев » TBB
> У нас, к примеру, все работают в тесном коллективе, друг до друга идти пешком меньше пары минут.

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

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

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

Но в данном случае я имел в виду просто отдельный каталог на сервере с с архивом электронной литературы, которая имеется в фирме и распределена по компьютерам отдельных людей.

> Нет проблем и есть такие дяди, и есть их книги с прилагаемыми к ним носителями информации... Платите и пользуйтесь на здоровье. ;)

К сожалению, качество многих книг оставляет желать лучшего.

> Здесь вообще запутали две темы: отсутствие технологии и решение посторонних проблем. IMHO здесь близко проходит только один вопрос: корректная постановка задачи.

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

[Нет ответов на это сообщение]
2002-12-27 07:52:49
tchingiz » Всем
Добрый день - с наступающим новым годом

от нашего стола - вашему столу :))

вот почти законченное изложение мыслей по
поводу кризиса разработки программного обеспечения
http://www.sql.ru/forum/actualthread.aspx?bid=24&tid=17882
[Нет ответов на это сообщение]
2002-12-27 07:58:40
tchingiz » Всем
специальными технологиями являются
например Vienna Development Method
или RAISE Development Method
http://www.iist.unu.edu/raise

в которых ДОКАЗЫВАЕТСЯ корректность следующего
шага кодирования из предыдущего и часто автоматическим
способом.
[Показать все ответы на это сообщение]
2002-12-27 18:11:07
Vladimir Kirichenko » tchingiz
The kinds of software development projects that will be able to benefit the most from RAISE are developments of systems with inherent complexity, either for data, algorithms, or concurrency, and with strong reliability requirements.

Typical applications could be: systems software, embedded systems or safety critical software.

Safety Critical - это не повседневная задача да? Насколько я чувствую разницу в таких задачах используется скорее подход "скольво вам нужно денег и когда вы закончите" в то время как тот софт с которого началась вся тема относиться скорее к "я заплачу не более... и готово должно быть к понедельнику". Потому что последствия и цена глюков подобного софта очень разная...
[Показать все ответы на это сообщение]
2002-12-27 22:54:56
tchingiz » Vladimir Kirichenko

Safety Critical - это не повседневная задача - согласен.

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

это чистой воды обычная задача.

и при разбоке шаблонов поиска на AWK - тут никакой безопастностью и не пахнет

- рядовой синтаксический анализатор.

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

она на их сайте доступна лежит.

я научился на нем (на ихнем языке без использования метода) описывать базы данных под рсубд.

P.S.
это так отсебятина.

кризис в разработке софтвера был всегда.

в 83 году, когда я стал 41 (наверно я всех членов команды не знал)

членом команды по моделированию полетов самолета на os/360 про кризис уже трубили полным ходом.

а картинки из книги Вельбицкого до сих пор радуют глаз актуальностью.

(впрочем он их содрал еще откудато - что подчеркивет древнее происхождение кризиса)

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

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

[Нет ответов на это сообщение]
2002-12-27 23:00:40
tchingiz » Vladimir Kirichenko

боже я такого не хотел постить.

а заканчивают свои проекты они существенно быстрее.я намекаю на разницу в ваших постановка - "когда вы закончите" и "что бы было к понедельнику"

[Нет ответов на это сообщение]
2002-12-28 00:01:38
tchingiz » Сергей В. Сычев

по поводу классификации ошибок и предложений по их устранению я держал в руках отчет фирмы TRW "характеристики качества программного обеспечения" от некоего Боема. при ссср был издан в районе 85 года. точно не могу указать ссылку. сорри. в статье Прехельта (http://www.osp.ru/os/2000/12/045.htm) есть ссылка на Боема (3] B.W. Boehm, Software Engineering Economics, Prentice Hall, Englewood Cliffs, N.J., 1981 )

- по общим признакам я уверен - это тот же самый

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

[Показать все ответы на это сообщение]
2002-12-30 18:38:01
NKudinov » tchingiz
Ознакомившись с RSL видно , что
1) Возможности его применения ограничены
(Например, трудно применить в системах основанных на взаимодействии с пользователем)
2) Использование не решит задачу создания качественного ПО.
( С ошибками можно писать и на нем. Притом легко :-). )

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

[Показать все ответы на это сообщение]
2002-12-30 21:58:42
tchingiz » NKudinov

V.S. Alagar, K.Periyasamy, Specification of Software Systems, Springer, 1998 -

обсуждает проблемы создания качественного по. рассматриваются Z, WDM, Larch/C++

>Ознакомившись с RSL видно , что

за два дня?

:))))))))))))))))

RSL - это одна из конструктивных математик

сравнить с "ознакомившись за два дня с матанализом". (явное влияние книжек типа

Оракл для занятых за 24 урока)
:))))))))))))))))))))))))))))

>1) Возможности его применения ограничены

>(Например, трудно применить в системах основанных на взаимодействии с
>пользователем),

например, кайз стадис показывает широту границ использования. тут есть психологическая разница - как пишет промоутер (MS) про свои продукты (оголтелая пропаганда на уровне геббельса - про проблемы вы узнаете потом, когда деньги заплачены), и как пишет ученый - руководство про применению c подчеркиванием проблем и границ применения.

>2) Использование не решит задачу создания качественного ПО.
>( С ошибками можно писать и на нем. Притом легко :-). )

:)))))))))

писать с ошибками легко можно на всем. тяжело компилировать потом. rsl позволяет писать кратко (меньше текста - меньше ошибок) и отлавливает больший
класс ошибок.


rsl - проработанная технология - именно технология повышает качество продукта
(конвеер), а не разговоры про совесть и ответственность разработчика.
------------

мысли уважаемого Лебедева про ступенчатый метод со сслыкой на Гамма Э., Хелм
Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования.

Паттерны проектирования. ? СПб.: Питер, 2001
проходят красной нитью через всю историю программирования. я их читал в
работах академика Глушкова за 1960 годы, например. отечественная P-технология
и RSL Development Method есть применение этих мыслей к жизни.

[Нет ответов на это сообщение]
2002-12-30 22:04:35
tchingiz » Всем

http://www.cs.iastate.edu/~leavens/larchc++.html

http://s3.informatik.uni-essen.de/publications/
http://www.cs.concordia.ca/htbin/fac_page.cgi?Alagar

:)

[Нет ответов на это сообщение]
2003-01-05 17:01:33
Сергей В. Сычев » tchingiz

Добрый день! Вы пишите:

>для сокращения ошибок програмирования - главным подходом может быть только >сокращение числа строчек (операторов) получаемой программы - кол-во ошибок, >которые делает в тексте НЕ ЗАВИСИТ ОТ языка, на котором он пишет. это константа на >число строчек.

Да, этот подход не единственный, но, вероятно, действительно главный. В определенном смысле, идеалом программиста должен быть "код, которого нет, а функции его выполняются".

Спасибо за ссылки.

С Уважением,

[Нет ответов на это сообщение]
2003-01-05 17:12:35
Сергей В. Сычев » Кирилл Лебедев

>Пока я заметил немного другую закономерность: разные ошибки 1-2-го уровней могут >быть предотвращены/найдены с помощью мер разного уровня (...)

Где-то, я думаю, это начинает действовать начиная с 3-его уровня и выше. То есть, например, продуманной архитектурой (и не только) можно уменьшить количество кода при сохранении функций. Нет кода нет ошибок.

Могу прислать несколько примеров, если интересно.

С Уважением,

[Показать все ответы на это сообщение]
2003-01-05 17:21:50
Serega » Всем

Для тех, кто еще не читал - веселенькая, хотя и старая ссылка к праздникам:-)

http://www.livejournal.com/talkpost.bml?journal=alconaft&itemid=602

[Нет ответов на это сообщение]
2003-01-05 17:40:00
Андрей Жуков » NKudinov

Добрый вечер! Цитирую:

>1)Есть и другие младенческие профессии ( по сравнению с >строительством)

Конечно, но с этим никто не спорил. Между тем, под "молодостью", как я понял, в контексте настоящего обсуждения понимается не только (и не столько) буквальный возраст (у иных профессий "детство" продолжалось сотни лет), сколько "болезни роста", признаки которых следущие:

- внутреннее (на уровне позиции) cопротивление стандартизации;

- желание любой проект понимать, как уникальный;

- желание видеть свою профессию сверх-уникальной (это по человечески понятно, но мешает проводить полезные аналогии);

- стремление действительно работать "по ремесленечески" - то есть, "по полному циклу" от начала и до конца без разделения функций ;

- нежелание нормировать свою работу и отвечать за сроки;

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

- и др.

Кроме того, Вы пишите:

>2)Все проблемы в программировании из-за отсутствия законов >программирования.

Это очень интересное замечание. Не могли бы Вы раскрыть его подробнее? Что Вы вкладываете в понятие "закон"?

Cпасибо,

[Нет ответов на это сообщение]
2003-01-07 23:26:17
Кирилл Лебедев » Сергей В. Сычев
[i]Где-то, я думаю, это начинает действовать начиная с 3-его уровня и выше. То есть, например, продуманной архитектурой (и не только) можно уменьшить количество кода при сохранении функций. Нет кода нет ошибок.
Могу прислать несколько примеров, если интересно.[/i]

Очень интересно. Буду благодарен.

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

С уважением, Кирилл

[Нет ответов на это сообщение]
2003-01-08 10:19:34
Силантьев Сергей » therapy.narod.ru
>> Ведь нужно говорить не о смертности, а о продолжительности жизни.

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

2. Безусловно хороший программист должен нести ответсвтенность за свой продукт, но в равной степени должен нести такую же ответсвенность и Поставновщик Задачи. Они ОБА должны нести ответственность. Как постановщик задачи объяснит цели и задачи будущего АРМ, так программист(хороший) и выполнит эту задачу и достигнет поставленной цели. Схема "Нужно написать то-то, но это должно работать ещё вчера и по нажатию одной кнопки, а если не напишешь, но не заплатим..." как раз и порождают кучу ошибок и проблем.

3. Самообразование. Поиск новых решений. Изучение новых технологий, в том числе и новых способов организации производственного процесса программистов. Мне кажется к этому должен стремиться хороший рограммист.

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

P.P.S. Хочу лишь добавить, что почему то никто из (удалено Редакцией с предупреждением) не упомянул таких деталей:
- программист, прежде чем начать выполнять проект, ДОЛЖЕН изучить предметную область, которую он будет "программировать", но сам заказчик НЕ ДОЛЖЕН изучать языки программирования, технологии и др., с помощью которых будет реализовываться его задача.

Лично я, попутно, за 10 лет работы по специальности изучил технологический процесс создания пластиковых окон и дверей, процесс работы автозаправочных станций, бухгалтерский и товарный учёт и др... Сейчас вот изучай технологический процесс производства мороженного :))

3P.S. Программисты (настоящие) - народ плечистый. (удалено Редакцией со вторым предупреждением).
[Показать все ответы на это сообщение]
2003-01-08 10:55:15
Редакция » Силантьев Сергей

Уважаемый Сергей Силантьев!

На этом Форуме принято корректно общаться с коллегами.

[Показать все ответы на это сообщение]
2003-01-08 11:08:37
Силантьев Сергей » Редакция
Приношу свои извинения, если кто-то посчитал, что я пытался кого-то обидеть.

Может быть было немного эмоционально в конце...

Всех с Новым Годом! :))

[Нет ответов на это сообщение]
2003-02-04 06:32:00
tchingiz » Всем

пытался найти ссылку на занятную работу
Klaus Renzel Error Handling for Business Information Systems от 16.01.2003
и нашел список литературы


http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm

Appendices/literature.htm

и

http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm

[Нет ответов на это сообщение]
2003-02-24 11:56:50
Георгий Соколов » Всем
             Уважаемые коллеги!
 
По поводу Интернета и программистов меня порадовал деревенской простотой и ясностью руководитель Коммунистической партии PФ  Зюганов Г.А:
 

"Компьютерные технологии внедряются во все сферы жизни государства и общества. Благодаря созданию микропроцессора компьютер из достояния узкого круга исследователей, плановиков и политиков превратился в бытовой прибор. По своему культурному значению это сравнимо только с изобретением книгопечатания. Теперь уже и личная жизнь человека начинает все больше и больше зависеть от систем информации и коммуникации. И хотя до сих пор подавляющее большинство пользователей персональных компьютеров лишь самозабвенно забавляется, играя в электронные игрушки или малоосмысленно ползая по Интернету, результат уже есть. Персональный компьютер превратился в эффективное орудие формирования вполне определенного культурного стереотипа. То есть появилась техническая возможность формирования в мировом масштабе единой системы ценностей, единого образа жизни.  Отсюда, с одной стороны, возникает объективная потребность во всемирном Центре политического и экономического регулирования, а с другой - формируются материально-технические возможности возникновения и функционирования подобного центра".

 

И далее:

 

"С изменением характера труда безвозвратно уходят времена, когда производству требовался частичный работник — человек-винтик. В современных передовых отраслях неуклонно возрастает удельный вес умственного труда. Научно-исследовательские и опытно-конструкторские разработки, информационно-программное обеспечение становятся неотъемлемой, а нередко и ведущей частью производства. Ряды производительных работников все больше пополняются представителями научной и технической интеллигенции. На этой основе постепенно складывается новое передовое ядро рабочего класса, включающее в себя работников производительного — физического и умственного труда. Они объединены научной организацией производства и сознательной дисциплиной, современными технологическими процессами, требующими высокой степени координации трудовой деятельности, постоянного творчества, высокой специальной подготовки и общекультурного развития.  Современный передовой класс — носитель социального прогресса и выразитель общенародных интересов. Это, во-первых, производители вещественного, высокотехнологического и наукоемкого продукта (hardware) — ученые, конструкторы, технологи, управляющие, квалифицированные рабочие, в деятельности которых преобладает умственный труд. Это, во-вторых, производители невещественного, программного продукта (software), обеспечивающего функционирование производственных и информационных систем и социальной инфраструктуры. В деятельности этого отряда трудящихся в качестве ведущей производительной силы выступают наука, научное знание, высокое индивидуальное развитие самого работника. Это, в-третьих, все те, кто обеспечивает воспроизводство самого человека как субъекта труда и общественной жизни,— воспитатели, учителя, преподаватели вузов, врачи, производители услуг в сфере развивающего досуга и т.д. Сегодня именно через их труд осуществляются главные производственные инвестиции — вложения в человека, в его индивидуальное развитие. Поэтому они также являются в полном смысле слова производительными работниками. По сути дела на наших глазах формируется новый рабочий класс — рабочий класс XXI века. Разумеется, до того, как все слои и представители рабочего класса достигнут уровня своего передового отряда, еще далеко, но именно по нему следует судить о подлинной силе и исторических возможностях рабочего класса в целом".

Цитируется по: Зюганов Г.А., Глобализация: тупик или выход?, М.,  ЗАО "Газета "Правда", 2001 г., страницы 8 и 39 (стоит 6 рублей).

[Нет ответов на это сообщение]
2003-02-28 00:03:50
Кирилл Лебедев » Всем
Уважаемые коллеги!

На тему ошибок появилось еще несколько статей:

http://www.homepc.ru/school/23034/
http://www.homepc.ru/doityourself/23242/
http://www.homepc.ru/doityourself/23256/
http://www.homepc.ru/school/23956/
http://www.homepc.ru/school/23991/

На мой взгляд, некоторые места указанных статей написаны либо слишком туманно, либо слишком растянуто (занудно). Так ли это на взгляд читателей?

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

Что еще, на Ваш взгляд, стоит учесть/добавить/удалить/изменить, чтобы повысить качество материала и статей?

С уважением,
[Нет ответов на это сообщение]
2003-06-13 17:06:09
Редакция » Всем

Уважаемый коллеги!

Обращаем Ваше внимание на материалы, созвучные тематике данного обсуждения:

[Нет ответов на это сообщение]
2003-07-20 17:09:11
Евгений » Всем

С ошибками можно бороться подробным отчетом.
В NormCAD - отчет включает все формулы, по которым производились вычисления.
http://www.normcad.da.ru

[Нет ответов на это сообщение]
2003-07-22 11:31:30
оленька! » Всем
Как я обажаю вас всех!! мои любимые программисты! наконецто я прочитала на этом форуме свое родное ;-)) Спасибо редакции за это!!
[Нет ответов на это сообщение]


Яндекс.Метрика