К>Спроси у заказчика, что он сам называет словом "баг" (или каким словом он пользуется).
К>А то вы еще подеретесь, горааччие парни.
К>И вообще, перейдите от сленга к литературному языку — с обычными словами возникает меньше проблем взаимонедопонимания, и уточнять проще.
ИМХО, понятие "баг" такого же плана как "точка", "число", "множество" и другие фундаментальные понятия, имеющие интуитивную природу. И также имеющие многочисленные определения, полезные в том или ином смысле и вредные или ошибочные в другом.
Изначально программа (вернее, ее отсутствие) — баг. Дальнейшие телодвижения сводят на нет одни баги, зато вносят другие. Поэтому программа, по большому счету, скопище багов.
Увы
К>Спроси у заказчика, что он сам называет словом "баг" (или каким словом он пользуется).
Собственно "bug", из-за чего и возник ничальный вопрос.
К>А то вы еще подеретесь, горааччие парни.
Это затруднительно, заказчик за три моря сидит
К>И вообще, перейдите от сленга к литературному языку — с обычными словами возникает меньше проблем взаимонедопонимания, и уточнять проще.
Мечтать, увы, не вредно... Если-бы это ещё от меня зависело.
А всё равно полезно иметь ссылку на какой-нибудь майкрософтовский глоссарий с термином "bug".
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Здравствуйте, Zar, Вы писали: Zar>>Хочешь получить определение термина, хотя бы возьми на себя труд написать его. Я не знаю, что ТЫ подразумеваешь под словом bug. Может у тебя в микрокоде ошибка, а может в кристаловском отчёте, а мож в ДНК...
ДМ>Меня больше всего интересует что под этим термином понимает MS.
К>>Есть спецификация. Например, описание того, как функция должна работать. Чего ждет заказчик. И тому подобное. К>>Есть реальное поведение программы. (фича, англ. feature — особенность, свойство). К>>Если они не соответствуют друг другу, это ошибка, т.е. баг.
ДМ>Вот именно что спецификации, а не ожиданиям заказчика. Отсюда и вопрос.
А потом прийдёт заказчик и скажет фразу от которой вся команда разработчиков постареет на 10 лет: "Вы сделали то что я сказал, но не то, что я хотел"
Здравствуйте, Anatoliy Elsukov, Вы писали:
К>>>Есть спецификация. Например, описание того, как функция должна работать. Чего ждет заказчик. И тому подобное. К>>>Есть реальное поведение программы. (фича, англ. feature — особенность, свойство). К>>>Если они не соответствуют друг другу, это ошибка, т.е. баг.
ДМ>>Вот именно что спецификации, а не ожиданиям заказчика. Отсюда и вопрос. AE>А потом прийдёт заказчик и скажет фразу от которой вся команда разработчиков постареет на 10 лет: "Вы сделали то что я сказал, но не то, что я хотел"
Если у разработчиков нормальный руководитель, то поседеет не разработчик, а заказчик. Прочему разработчик отвечает за тот бред, под которым заказчик поставил подпись? Подписал — плати. А что бы не случилось ещё и сердечного приступа, программа отдаётся в тестирование готовой на 50%. Что бы у заказчика как можно больше времени было на "коррекцию курса". (Дополнительные требования к ТЗ)
Zar>Если у разработчиков нормальный руководитель, то поседеет не разработчик, а заказчик. Прочему разработчик отвечает за тот бред, под которым заказчик поставил подпись? Подписал — плати. А что бы не случилось ещё и сердечного приступа, программа отдаётся в тестирование готовой на 50%. Что бы у заказчика как можно больше времени было на "коррекцию курса". (Дополнительные требования к ТЗ)
К сожалению это идеал... а вообще всё действилтельно зависит от того с кем работаешь и как договорились.
Здравствуйте, Maydyk, Вы писали:
M>Привет! Назрел тут достаточно серьёзный вопрос. M>А что, собственно, мы считаем багой? Вернее, M>есть-ли в каклм-нибудь уважаемом месте (например MSDN) M>точное определение бага? Поиск пока ничего не дал.
Посмотри, например, здесь.
Там, в часности, приведены другие понятия, которые за собой скрывает емкое слово "баг".
Почти в самом конце этой странички есть ссылка на
IEEE Standard 610.12-1990. IEEE Standard Glossary for Software Engineering Terminology.
Если есть возможность познакомиться с этим стандартом,
то там ты найдешь определения разных вариаций багов.
На самом деле твой вопрос очень не простой и умение компании хотя бы
просто подсчитвать число "багов" в своем продукте говорит о многом.
Из других ссылок можно еще посмотреть здесь.
Вообще, поищи в интернете ссылки по словам "defect error software".
Они, возможно выведут тебя к чему-то интересному.
Здравствуйте, Anatoliy Elsukov, Вы писали:
Zar>>Если у разработчиков нормальный руководитель, то поседеет не разработчик, а заказчик. Прочему разработчик отвечает за тот бред, под которым заказчик поставил подпись? Подписал — плати. А что бы не случилось ещё и сердечного приступа, программа отдаётся в тестирование готовой на 50%. Что бы у заказчика как можно больше времени было на "коррекцию курса". (Дополнительные требования к ТЗ)
AE>К сожалению это идеал... а вообще всё действилтельно зависит от того с кем работаешь и как договорились.
Ну, как показывает практика, и это далко не идеал... Но у нас работа построена именно так. По поводу действительности — я написал: "Если у разработчиков нормальный руководитель" — вот ключевая фраза!
[]
Vi2>Изначально программа (вернее, ее отсутствие) — баг. Дальнейшие телодвижения сводят на нет одни баги, зато вносят другие. Поэтому программа, по большому счету, скопище багов.
Вот она, истинная философия программирования!
Можно опубликовать? С сохранением копирайтов, разумеется.
Здравствуйте, Zar, Вы писали:
Zar>Прочему разработчик отвечает за тот бред, под которым заказчик поставил подпись?
Разработчик еще как отвечает за бред, потому как он тоже ставит свою подпись.
Одна из задач разработчика — не допустить, чтобы бред был подписан.
В мире уже были случаи судебных разбирательств, когда заказчик
отказывался платить за уже почти сделанный продукт.
Угадай в чью пользу было решение судей
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Zar, Вы писали:
Zar>>Прочему разработчик отвечает за тот бред, под которым заказчик поставил подпись?
B>Разработчик еще как отвечает за бред, потому как он тоже ставит свою подпись. B>Одна из задач разработчика — не допустить, чтобы бред был подписан. B>В мире уже были случаи судебных разбирательств, когда заказчик B>отказывался платить за уже почти сделанный продукт. B>Угадай в чью пользу было решение судей
Здравствуйте, Maydyk, Вы писали:
M>Привет! Назрел тут достаточно серьёзный вопрос. M>А что, собственно, мы считаем багой? Вернее, M>есть-ли в каклм-нибудь уважаемом месте (например MSDN) M>точное определение бага? Поиск пока ничего не дал.
bug /n./
An unwanted and unintended property of a program or piece of hardware, esp. one that causes it to malfunction. Antonym of feature. Examples: "There's a bug in the editor: it writes things out backwards." "The system crashed because of a hardware bug." "Fred is a winner, but he has a few bugs" (i.e., Fred is a good guy, but he has a few personality problems).
Historical note: Admiral Grace Hopper (an early computing pioneer better known for inventing COBOL) liked to tell a story in which a technician solved a glitch in the Harvard Mark II machine by pulling an actual insect out from between the contacts of one of its relays, and she subsequently promulgated bug in its hackish sense as a joke about the incident (though, as she was careful to admit, she was not there when it happened). For many years the logbook associated with the incident and the actual bug in question (a moth) sat in a display case at the Naval Surface Warfare Center (NSWC). The entire story, with a picture of the logbook and the moth taped into it, is recorded in the "Annals of the History of Computing", Vol. 3, No. 3 (July 1981), pp. 285--286.
The text of the log entry (from September 9, 1947), reads "1545 Relay #70 Panel F (moth) in relay. First actual case of bug being found". This wording establishes that the term was already in use at the time in its current specific sense -- and Hopper herself reports that the term `bug' was regularly applied to problems in radar electronics during WWII.
Indeed, the use of `bug' to mean an industrial defect was already established in Thomas Edison's time, and a more specific and rather modern use can be found in an electrical handbook from 1896 ("Hawkin's New Catechism of Electricity", Theo. Audel & Co.) which says: "The term `bug' is used to a limited extent to designate any fault or trouble in the connections or working of electric apparatus." It further notes that the term is "said to have originated in quadruplex telegraphy and have been transferred to all electric apparatus."
The latter observation may explain a common folk etymology of the term; that it came from telephone company usage, in which "bugs in a telephone cable" were blamed for noisy lines. Though this derivation seems to be mistaken, it may well be a distorted memory of a joke first current among telegraph operators more than a century ago!
Or perhaps not a joke. Historians of the field inform us that the term "bug" was regularly used in the early days of telegraphy to refer to a variety of semi-automatic telegraphy keyers that would send a string of dots if you held them down. In fact, the Vibroplex keyers (which were among the most common of this type) even had a graphic of a beetle on them! While the ability to send repeated dots automatically was very useful for professional morse code operators, these were also significantly trickier to use than the older manual keyers, and it could take some practice to ensure one didn't introduce extraneous dots into the code by holding the key down a fraction too long. In the hands of an inexperienced operator, a Vibroplex "bug" on the line could mean that a lot of garbled Morse would soon be coming your way.
Actually, use of `bug' in the general sense of a disruptive event goes back to Shakespeare! In the first edition of Samuel Johnson's dictionary one meaning of `bug' is "A frightful object; a walking spectre"; this is traced to `bugbear', a Welsh term for a variety of mythological monster which (to complete the circle) has recently been reintroduced into the popular lexicon through fantasy role-playing games.
In any case, in jargon the word almost never refers to insects. Here is a plausible conversation that never actually happened:
"There is a bug in this ant farm!"
"What do you mean? I don't see any ants in it."
"That's the bug."
A careful discussion of the etymological issues can be found in a paper by Fred R. Shapiro, 1987, "Entomology of the Computer Bug: History and Folklore", American Speech 62(4):376-378.
[There has been a widespread myth that the original bug was moved to the Smithsonian, and an earlier version of this entry so asserted. A correspondent who thought to check discovered that the bug was not there. While investigating this in late 1990, your editor discovered that the NSWC still had the bug, but had unsuccessfully tried to get the Smithsonian to accept it -- and that the present curator of their History of American Technology Museum didn't know this and agreed that it would make a worthwhile exhibit. It was moved to the Smithsonian in mid-1991, but due to space and money constraints has not yet been exhibited. Thus, the process of investigating the original-computer-bug bug fixed it in an entirely unexpected way, by making the myth true! --ESR]
bug-compatible /adj./
Said of a design or revision that has been badly compromised by a requirement to be compatible with fossils or misfeatures in other programs or (esp.) previous releases of itself. "MS-DOS 2.0 used \ as a path separator to be bug-compatible with some cretin's choice of / as an option character in 1.0."
Здравствуйте, Vi2, Вы писали:
Vi2>ИМХО, понятие "баг" такого же плана как "точка", "число", "множество" и другие фундаментальные понятия, имеющие интуитивную природу. И также имеющие многочисленные определения, полезные в том или ином смысле и вредные или ошибочные в другом.
Vi2>Изначально программа (вернее, ее отсутствие) — баг. Дальнейшие телодвижения сводят на нет одни баги, зато вносят другие. Поэтому программа, по большому счету, скопище багов.
Здравствуйте, Zar, Вы писали:
B>>В мире уже были случаи судебных разбирательств, когда заказчик B>>отказывался платить за уже почти сделанный продукт. B>>Угадай в чью пользу было решение судей
Zar>Я думаю, в пользу тех, у кого адвокаты лучше.
Может и так, но после подобного разбирательства (не важно к чему придут судьи),
на компании разработчиков можно ставить крест.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Здравствуйте, TK, Вы писали:
TK>>ms-help://MS.MSDNQTR.2002OCT.1033/dnstone/html/stone11132000.htm
ДМ>Простите, не затруднит-ли Вас привести заголовок этой статьи, переход по гиперссылке в моей версии MSDN не работает.
ДМ>Вот именно что спецификации, а не ожиданиям заказчика. Отсюда и вопрос. ДМ>Проблема, думаю, понятна. В спецификации поведение программы не определено, но, ДМ>как оказалось оно не соответсвует ожиданиям заказчика. И вот это называется ДМ>грозным словом bug. А стоит задача доказать обратное.
Ну причём тут строгие определения. Это, брат, не наука. Это искусство. Как построить такие отношения с заказчиком, чтобы в случае несоответствия спецификаций ожиданиям оформлялись change request'ы, а не баги. (а то и просто следующая версия программы заказвалась бы) ))
Trying is the first step toward failure. (c) Homer J. Simpson
0 программистов ругал сердитый шеф,
потом уволил одного, и стало их FF!