Истоки Agile и взаимосвязь с другими областями
Истоки Agile 1.1 Краткая история компьютерных технологий
Скачать 45,4 Kb.
|
Реферат Егай 105уит
1. Истоки Agile1.1 Краткая история компьютерных технологий.Первое электронное устройство, в названии которого было слово «computer», это ENIAC (Electronic Numerical Integrator and Computer), который разрабатывался в 1942–1945 годах и работал 10 лет, до 1955 года. Это было детище ученых, которые сами его проектировали, создавали, отлаживали и вообще лучше всех в нем разбирались. Программировали его физически, переключая тумблеры и штекеры. Иногда для небольшого изменения логики требовалось переключить порядка сотни тумблеров и штекеров. Устоявшихся стандартов разработки программ еще не существовало. Ученые постоянно экспериментировали и при разработке программ каждый из них делал так, как считал нужным. Так как количество людей, которые занимались программированием, было очень мало, то никаких подходов к менеджменту разработки программного обеспечения (ПО) не существовало в принципе. Просто потому, что в этом не было потребности. О массовой разработке речи пока не шло. Знания, необходимые для разработки ПО, были очень специфичные, и мало кто в мире вообще понимал, о чем идет речь. Порог вхождения был очень высокий : надо было обладать высшим образованием, ученой степенью, и к тому же быть включенным в соответствующую научную программу по работе с компьютерной техникой (зачастую военную). Это было время, про которое говорят, что «компьютеры были большими, а программы маленькими». Для примера — ENIAC весил 30 тонн, содержал 18 000 радиоламп, имел размеры 2,5×30 метров и обеспечивал выполнение 5000 сложений и 360 умножений в секунду. По нынешним временам ENIAC представлял собой очень большой калькулятор. При этом программы, которые готовили для ENIAC, имели размер всего несколько десятков бит информации. Сравните это с размером программы калькулятора сейчас — счет идет на Мегабайты ( 2.8 Мегабайта ), то есть больше миллиона бит информации. По мере накопления опыта стали выделяться типовые задачи и способы их решения. Возникла необходимость сохранять и быстро повторять алгоритмы. Для этого придумали перфокарты. Наверно, некоторые из вас даже помнят такие картонные карточки, в которых были пробиты дырочки, последовательность которых хранила последовательность действий, которые должен выполнить компьютер для решения задачи. Это сильно облегчило работу с компьютером, но не решало проблему экспертных знаний и высокого порога вхождения в мир разработки ПО. Между тем потребность в массовой разработке встала во весь рост, и все начало меняться. Начало массовой разработки ПО было положено в 1957 году, когда компания IBM презентовала первый язык программирования высокого уровня Fortran (Formula Translator). Он предоставлял возможность создавать программы на понятном для обычного человека языке (английском), а не переключая тумблеры или пробивая дырки в перфокарте. Вслед за этим стали появляться другие языки высокого уровня, что привело к взрывному росту объемов разработки ПО. Всякий, кто освоил синтаксис такого языка программирования, изучил правила работы и справился с компилятором, считал себя программистом. Зачастую разработка новой программы выглядела так: Заказчик и Программист садились рядом, обсуждали чего хочет Заказчик, и Программист говорил — «я все понял» и уходил на полгода в разработку. В меру своего понимания Программист, делал «нечто», что, как он думал, нужно Заказчику. Заказчик получал это «нечто», и пытался его использовать, но либо с ходу натыкался на ошибку, либо не мог нормально работать, т.к. было неудобно. Приходилось переделывать. За деньги Заказчика опять же. В процессе разработки Заказчик обязательно вспоминал что-то, что он забыл попросить Программиста сделать, прибегал к нему с «ценными замечаниями и дополнениями», что меняло направление разработки и сдвигало срок окончания. Так как Программист обладал всей полнотой экспертизы в разработке программ, то он сам проектировал программу, разрабатывал, тестировал и упаковывал для отправки Заказчику. Никакого разделения труда не существовало. Надо ли говорить, что это не способствовало качеству конечного продукта, т.к. «глаз замыливался» и Программист не видел совершенно очевидных дефектов или даже не считал их дефектами. При этом, друг друга Заказчик и Программист понимали очень плохо. Для Заказчика Программист говорил слишком сложным языком, а Программисту Заказчик казался оторванным от реальности фантазером. Такой подход к разработке программ назвали «Code & Fix», и к сожалению, он встречается и сейчас. Как следствие, временные рамки и бюджеты проекта становились непредсказуемыми, конечный результат тоже было трудно предсказать. Программист, как эксперт, считал, что он лучше всех понимает, что нужно делать и часто игнорировал желания Заказчика. Заказчик платил деньги и ожидал, что Программист будет делать то, за что было заплачено. Но этого не происходило. В конечном итоге, в режиме «Code & Fix» разработка программы заканчивалась либо тогда, когда у Заказчика кончалось терпение, либо тогда, когда исчерпывался бюджет. Причина этих проблем была в отсутствии общих стандартов и подходов к разработке ПО. В 60-80х годах XX века, отсутствие такого рода стандартов и правил привело к полноценному мировому кризису разработки программного обеспечения (software crisis). Во всем мире в проектах по разработке ПО наблюдались одни и те же нерешаемые проблемы: Проекты всегда превышали бюджеты; Реализация проекта всегда превышала оговоренные сроки; Итоговое ПО неэффективно решало возложенную на него задачу (тормозило, нестабильно работало и т.д.); Итоговый результат был низкого качества; Проекты были неуправляемыми, а код было сложно поддерживать; Разработке не было видно конца, и в конечном итоге, заказанное ПО никуда не поставлялось и не использовалось Скачать 45,4 Kb. Поделитесь с Вашими друзьями:
|