Деминг и качества разработки программного обеспечения
Хорошее представление о философии Деминга может способствовать непрерывное улучшение качества программного обеспечения.
Вот уже несколько лет, одна из наиболее быстро растущих сегментов экономики США была индустрии программного обеспечения. Это включает в себя общие цели программного обеспечения, индивидуальные разработчики программного обеспечения и специализированных организаций, таких, как НАСА и военные. Согласно результатам опроса проведенного промышленности экономист мая 1996, годовой доход превышает $ 200 млрд с темпом роста примерно на 13 процентов, препятствуя росту скорости роста для остальной части экономики. Уже важным компонентом ВВП, быстрый рост в производстве программного обеспечения, как ожидается, сохранится и в обозримом будущем. Это одна из ключевых отраслей будущего, говорит Туроу (1992), и Соединенные Штаты являются мировым лидером с точки зрения производства, так и исследований и разработок.
Отчасти потому, что это молодой, но растущий хорошо, а отчасти потому, что он имеет особые характеристики, которые отличают его от других отраслей промышленности, индустрии программного обеспечения до сих пор не серьезное воздействие на "качество революции", которая пронеслась по обрабатывающей промышленности в последние десятилетия. Это довольно яркий наблюдения, поскольку, как отметил В. Эдвардс Деминг, пионера революции, компании, которые в настоящее время занимается также находятся в благоприятном положении для улучшения качества. Эти компании, сказал он, также самый большой долг лучше, если они хотят сохранить свою удачу. По Niederman и др.. (1991), качество стали неотъемлемой частью разработки программного обеспечения, и его значение, вероятно, возрастет, как конкуренция усиливается. Можно с уверенностью сказать, что качество будет основным фактором успеха для производителей программного обеспечения, как индустрия продолжает пожилые во всем мире.
Объем производства программного обеспечения оффшорных также растет экспоненциально в последние годы. Это который отчасти из-за нехватки специалистов по программному обеспечению и программистов в США, и частично за счет других развивающихся стран, таких, как Индия, которые ведут пути в становлении недорогих поставщиков программного обеспечения. Из-за быстрого улучшения в глобальной телекоммуникационной, в частности, расширение сети Интернет, географические границы, которые когда-то охраняемых США и другие западные рабочие теряют свое значение. "Глобальная деревня" это уже не фантазии перспективе, поскольку на рынке разработки программного обеспечения легко доступными во всем мире - по сути, в гораздо большей степени, чем разработки аппаратных средств. В отличие от аппаратного обеспечения, которое в основном общие (чипы фишки, если они приходят из картофеля), программное обеспечение для конкретного человека ресурсов, как в сфере производства и использования. И понимание Деминга к управлению человеческим ресурсам, как освежающее и важно сегодня, как это было, когда первый поддерживал.
Хотя точное определение качества программного обеспечения является неуловимое, что в конечном итоге связано с какой мере программное обеспечение удовлетворяет пользователей. Это выходит за рамки условий встречи потребностей пользователей и на такие критерии, как легкость изучения, простота использования, осуществления использования, и так далее. Эти факторы будут продолжать завоевывать власть, как использование программного обеспечения становится все более частью повседневной жизни большинства людей, независимо от их профессии. Это не достаточно для программного продукта, чтобы быть высокого качества для успеха на рынке, она должна удовлетворять своих пользователей в большей степени, чем другие альтернативы.
Основная философия всеобщего управления качеством (TQM) в том, что продукция или услуги будут становиться все лучше и дешевле, если пользователь требует постоянно анализируются и развития и производственные процессы, соответственно улучшилась. По отслеживания и анализа данных от пользователей и R
Чтобы использовать метафору Негропонте (1996), промышленной революции о переходе атомов, когда компьютер революции о перемещении бит. Обладая материальных ресурсов, таких как сталь или хлор, которые являются важными во многих физических процессов производства, не дает сравнительные преимущества в эпоху информационной революции. Компьютер, новая эквалайзер, преуспел в создании глобального рынка программного обеспечения - явление, которое Адам Смит, предусмотренных для всех товаров и услуг в Богатства народов ", но не был реализован на протяжении веков. В отличие от реального производства, основной вклад в программы развития человеческого знания и интеллектуальный потенциал, это особенно важно, как мы относимся к данному ресурсу. философии Деминга, качество идет о мышлении работников от "человека, психологическое время" ориентации. И его взгляды имеют непосредственное отношение к разработке программного обеспечения.
Процесс разработки программного обеспечения
Само собой разумеется, что понимание процессов разработки программного обеспечения имеет важное значение для управления ими должным образом. Всего четыре десятилетия назад, промышленности не существовало; разработка программного обеспечения в зачаточном состоянии. Каждый R
Старейших и простейших моделей разработки программного обеспечения и код-захода на посадку, в которых мало или вообще не перспективное планирование осуществляется до фактического начала кодирования. Так как продукт развивается, код проверяется, чтобы обнаружить и исправить какие-либо проблемы, а затем цикл повторяется до завершения проекта. Но поскольку в нем отсутствует перспективное планирование, код-и-захода на посадку строго ограничен в своем, способность обеспечить качество конечной продукции. Такие программы часто имеет ограниченную полезность и совместимость с другими программными продуктами, даже из того же производителя. Несмотря на все эти последствия, многие малые IS (информационные системы) магазины по-прежнему полагаться на код-и-захода на посадку из-за ошибочного убеждения, что более структурированные подходы предусматривают более высокие затраты и краткосрочные выгоды перевешивают долгосрочные потери.
Более структурированного подхода является так называемая модель водопада показано на рисунке 1. Разработка программного обеспечения предусматривается в плане развития жизни системы цикл, состоящий из нескольких этапов, которые последовательно от одного каскада к другому. Этапы включают в себя: планирование потребностей, в которой пользователь требования определены; определения продукта, в котором требования переводятся в спецификации, технические характеристики программного обеспечения и его компонентов; кодирования конкретные указания компьютера, тестирование и исправление кода и поддержание продукта используется с помощью обновления или модификации. Пунктирные стрелки указывают на возможность того, что в ходе работы на каждом этапе, это может быть необходимо вернуться назад и повторить некоторые мероприятия в рамках предыдущего этапа. Возможно, некоторые черты дизайна, возможно, потребуется быть добавлены, удалены или изменены.
[Рисунок 1 ИЛЛЮСТРАЦИЯ опущены]
Хотя некоторые обратной связи между этапами часто необходимо, он должен использоваться с предостережением, чтобы избежать "фальсификация" в процессе - то есть, внося изменения в ответ на наблюдаемый результат. Деминг считал, что подделка не обязательно влияет на желаемой цели, и часто приводят к результатам, которые еще дальше от целевые характеристики. Он использовал "воронка эксперимент", чтобы проиллюстрировать бесполезности подкупа производственного процесса и, чтобы подчеркнуть наличие изменчивости в любом процессе. Вместо того, чтобы изменения в качестве реакции на исход, Деминг выступает за то, источники и характер изменчивости в процессе должны быть поняты и действия должны быть запланированы соответственно.
Две другие модели являются более совершенными, адаптации базовой модели водопада. Дополнительных модель включает производство программного обеспечения компонентов или модулей, которые могут быть разработаны гораздо быстрее, чем всю систему. В зависимости от дизайна и наличия ресурсов, эти компоненты могут быть сделаны последовательно или параллельно, что позволяет более гибко подходить к выделению ресурсов в проекте. Еще один вариант, называется итеративной модели, повторяет весь процесс создания несколько раз, пока конечный продукт выходит. Этот вариант предназначен для ситуаций, в которых требования и определения продукта, не известно с самого начала, но есть необходимость приступить к разработке ранней версии, которая будет в конечном итоге превратиться в конечный продукт. Ранние версии, которую иногда называют альфа-или бета-версии, дают пользователям возможность выявить и уточнить требования и определения продукта. Как и в модели водопада, постепенных и итерационные модели также могут быть подвержены фальсификации, поскольку это может быть невозможно провести различие между изменениями, которые позволят улучшить конечный продукт, и те, которые будут считать, дальше от желаемых результатов.
Правильно управления разработки программного обеспечения требует, чтобы понять процессы, определить и документально подтверждены. Общие модели такие, как упомянутые выше, имеют ограниченную полезность для этой цели, более конкретные и подробные определения необходимости. Это распространенная ошибка, рассматривать каждый проект развития уникальных и пусть он определить свои собственные процессы, как проект мероприятий на самом деле ведется. Хотя конечный продукт может быть уникальным, это не повод для отказа от усилий по определению, стандартизации и документирования процедур. Такое оправдание только приглашает на страдание, как далеко, как качество, стоимость и своевременности.
В отличие от более традиционных продуктов и услуг, основной характеристикой рынка программного обеспечения является волатильность и быстрых перемен. Новые технологии постоянно рождаются, новые области применения постоянно появляются. Новые обработки информации, методов, таких как клиент-серверного подхода, или рождение новых средах программирования, таких как Visual Basic или Java, порождают неопределенность и дорогостоящим выбор в принятии решений, разработки программного обеспечения. В противном случае для оценки этих изменений может приговором для разработчиков программного обеспечения. Но Есть не просто руководящие принципы для разработки стратегии для их принятия, за исключением быть готовым быстро продвигаться вперед. Чтобы использовать афоризм Деминга: "Если у вас нет конкурентов сегодня, вы получите один завтра".
Второй особенностью рынка является отсутствие барьеров для доступа. Тот, кто может развиться программного обеспечения могут иметь прямой доступ на рынок через Интернет по очень низкой цене. Это метод распределения, которая быстро становится довольно распространенным явлением. Потенциальные клиенты могут на самом деле попробовать продукт перед принятием решения о покупке. Они могут принимать непосредственное участие в тестировании и совершенствовании продукта без больших задержек. За редкими исключениями с участием индивидуальных (контракта) разработка программного обеспечения, обычные трудности в развитии и распространении производства не применяются в отношении программных продуктов.
Отсутствие барьеров для вступления также означает, что доля рынка трудно охватить и легко потерять. Программное обеспечение жизненного цикла продуктов гораздо короче, чем у традиционных продуктов, если программное обеспечение непрерывно совершенствуется. Чтобы увеличить шансы на долгосрочный успех, это не достаточно, чтобы производить качественный продукт изначально, еще более важно иметь план для его непрерывного совершенствования. VisiCalc был высококачественных электронных таблиц в 1970, но он быстро исчез после прибытия лучшим продуктом, Lotus 1-2-3 - что само по себе впоследствии потеряли долю на рынке еще более совершенного продукта. Microsoft Excel удалось оставаться на вершине не за счет более совершенного продукта на ее внедрение, а постоянно совершенствуется на протяжении многих лет лучше удовлетворять потребности своих пользователей. Оставаться в гармонии с клиентами, которая находится в центре философии Деминга, имеет первостепенное значение в условиях быстро меняющегося рынка программного обеспечения.
Особые характеристики разработки программного обеспечения, также связаны с важными потенциальных проблем, которые наиболее управления должны знать. Наиболее серьезные из этих вытекает из неспособности определить цель программного обеспечения охраны окружающей среды и потребностей пользователей до фактического реализация проекта развития. Для оказания помощи в установлении требований пользователей и определения продукта, конкретные модели под названием Software Quality функции развертывания (SQFD) было предложено (и будет обсуждаться позже). Другими важными проблемами являются недостаточное планирование задач в области развития и неспособность определить их ясно, нереальных сроков для завершения, недостаточный контроль и отсутствие дисциплины управления в выполнении плана развития (создание слишком много изменений, постоянное добавление новых функций). Кроме того, ряд серьезных проблем в программном обеспечении касаются развития человеческих ресурсов: нехватка людей, обладающих необходимыми навыками; текучесть кадров, и, самое главное, недовольство работников, которые в конечном счете может быть отнесена к управлению.
Деминг философии и разработки программного обеспечения
Прежде чем рассматривать конкретные модели, которые будут использоваться при планировании и реализации программы обеспечения качества, важно, чтобы подчеркнуть основные точки зрения Деминга: Качество философия управления, который должен быть принят в качестве образа жизни, а также способ ведения бизнеса. Если высшее руководство может принять эту философию и институционализации, эффективности конкретных инструментов обеспечения качества будет ограничено в лучшем случае. Деминг первоначально описал эту философию в 1982 книгу из кризиса, который стал известен в 14 точек, характеризующих организационные преобразования к качеству. В своем последующем книжку "Новая экономика, на которой он работал до своей смерти в 1993 году, Деминг пытался объяснить, как эта трансформация может быть достигнута. Средства преобразования, что он в конечном счете, называется "система глубоких знаний", которые должны быть приобретены и приняты со стороны руководства. Эта система глубоких знаний состоит из четырех взаимосвязанных частей:
* Признательность за системы;
* Знание о вариации
* Теории познания, а также
* Психологии.
Благодарность за системой начинается с признания того, что организации системы взаимосвязанных компонентов, которые работают вместе для достижения поставленных целей. Общая цель для всех, чтобы получить в конечном счете - покупателям, акционерам, сотрудникам, поставщикам, общества и окружающей среды, так. Управление системой требует знания взаимосвязи между всеми его компонентов, а также людей, которые работают в нем. Точки зрения системы подчеркивает необходимость сотрудничества и координации между департаментами, команды, и так далее. Отсутствие сотрудничества, таких, как острая конкуренция за денежное вознаграждение, может разрушить систему.
Примеры сбоев программного обеспечения проекта множество, потому что дизайнеры не смогли зрения различных компонентов системы в качестве подсистемы в целом. Именно поэтому системы, которая должна была осуществлять автоматическую проверку билетов и багажа на Стэплтон Международный аэропорт Денвера с треском провалилась и привела к гибели миллионов долларов - хотя каждый из ее компонентов по-видимому современное состояние. Принципы теории надежности говорят нам, что вероятность того, что система становится хрупким является значительным, даже тогда, когда каждая подсистема в целом весьма прочными.
Знания об изменении начинается с признания того, что всегда есть некоторые различия в любом процессе, - между людьми, в выходной, в службе, в продукте. Открывая причины изменчивости и оценить их очень важно. Строгие сроки, даже если они основаны на оценке средних, которые не согласуются с пониманием вариации. Ни численные цели или квоты. Лучше работать по методам улучшения процесса, тем самым уменьшая отклонение от идентифицируемых причин и достижения желаемых результатов. Деминг считал, что вместо введения цифровой целей или квот, работники должны быть обеспечены методы, средства и обучение в которой результаты должны быть достигнуты. Как он выразился, "Каким способом?
Теории познания, дает возможность принимать рациональные прогнозы будущих наблюдений на основе информации о прошлом, вместе с теорией, которая связывает прошлое и будущее. Управление требует предсказания, которые, в свою очередь, требует теории познания. Информация не есть знание; словарь содержит информацию, но не знания. Без теории познания, нет возможности использовать информацию, которая становится доступной. Теории в конечном счете может оказаться неправильным, но оно тем не менее, необходимые для принятия прогнозов. "Интернет рухнет, потому что физические сети в скором времени будет перегружен" предсказание на основе теории о сетях, так это заявление "Интернет станет магистрали для всех, потому что пропускная способность сети будет совершенствоваться". Тот, кто делает ставку на ошибочная теория, по крайней мере участвовали в бою, но те, кто не теория не имели возможности.
На меньших масштабах, предсказание, что программный продукт будет работать как должно быть основано на теории программного обеспечения. факультетов информатики начинают предлагать курсы по формальные методы доказательства правильности программы для ЭВМ. Теория программного обеспечения, уже позволяет производить компьютерные программы, которые генерируют код для другого программного обеспечения, это станет еще более распространенным явлением и в будущем. С другой стороны, теория человеческой психологии позволяет предсказать, что люди всегда хотят контролировать то, что их программное обеспечение делает, поэтому, кроме повседневных задач, они не будут полностью полагаться на компьютерные программы.
Психология помогает нам понять людей и их отличия друг от друга. Люди учатся по-разному, работают по-разному и имеют различные источники мотивации. Это общее заблуждение, например, что программное обеспечение инженеры и программисты предпочитают взаимодействует с компьютером, чтобы общаться с людьми, или что они будут лучше работать только в ячейке весь день. Они люди первом, и люди весьма разнообразны (вариант опять!). Управление должно быть в курсе всех этих различий и использовать это понимание для оптимизации сотрудников способностей и склонностей.
Как правило, руководство сегодняшней практики лечить людей, как будто они все похожи в том, как они работают и производят. Такая философия находит свое отражение в исполнении оценки по некоторым произвольно введенных стандартов. Эти методы должны быть брошены на то, как люди находят новые или иные способы производства и вклад в систему, в которой они работают. Это необходимо понять и оценить, что большинство трудящихся "только рады делать свою работу хорошо, и это ответственность руководства, чтобы помочь им достичь. Организации, которые занимаются их человек ресурсов с этой точки зрения будет в живых лиц в долгосрочной перспективе.
TQM инструменты для разработки программного обеспечения
В последние годы усилия по реализации философии качества разработки программного обеспечения дали две модели, которые стали известны. Одним из них является модель SQFD упоминалось ранее, а другой процесс Capability Maturity Model (СММ), разработанной др. Полк и др. в Институте программной инженерии (SEI) в Карнеги-Меллона.
SQFD является адаптацией развертывания функции качества модели, предложенной Салливан (1986), как стратегическое средство для общего управления качеством. Основное внимание она уделяет требования планирования этап жизненного цикла разработки системы. Улучшение качества на этом этапе может привести к уменьшению изменения в дизайне, увеличение аналитик и программист производительность, меньшее количество ошибок прошло от одного этапа к другому, и, наконец, программные продукты, которые в большей степени способны удовлетворить требованиям заказчика. Идея введения качества на стадии проектирования был разработан для производственных процессов по Тагути, чтобы обеспечить, что он назвал "надежной качество" (Тагути и Клаузинг 1990). Эта идея также основания "дом качества" матрицы Хаузер и Клаузинг (1988). Как планирования потребностей и техники определения продукта, SQFD также заимствует из этих идей. Конкретные шаги, показано на рисунке 2, приводится ниже.
[Рисунок 2 ИЛЛЮСТРАЦИЯ опущены]
Шаг 1. Потребности клиентов Запрашиваются и заносятся в форму отчетности с использованием клиентов собственной терминологии (например, "прост в использовании"). Они изучали, развернутая, а также организованы ряда требований / спецификаций матрицы.
Шаг 2. Требования используются для создания технической (инженерной) технические характеристики препарата. "Удобство в использовании", например, могут быть преобразованы в "времени для завершения учебник" и "число он-лайновых помочь". Клиенты должны продолжать принимать участие в разработке этих спецификаций, которые составляют колонны требования / спецификации матрицы.
Шаг 3. Клиенты просили оценить силу взаимосвязи (корреляции) между собой требований и технической спецификации. "Удобство использования" можно считать сильно коррелируют с "времени для завершения учебник", но не с "возможность печатать в горизонтальном режиме" или "объем оперативной памяти требуется". Оценка корреляции часто субъективны, и они могут или не могут быть выражены по цифровой шкале. В некоторых случаях данные могут быть доступны для вычисления статистических оценок коэффициентов корреляции.
Шаг 4. Клиенты просят вес приоритетов для удовлетворения своих потребностей. В результате оценки могут несколько отличаться, поэтому команда проекта предпринята попытка определить степень консенсуса между ними и присвоить числовые веса. Они, как правило, превращается в процентах, с тем чтобы общий вес всех требований 100 процентов.
Шаг 5. Технические параметры приоритетов разработанные с использованием начисленных сильных связей и значение веса. Если сильные отношения оцениваются по цифровой шкале, то приоритетом для заданной спецификации рассчитывается путем умножения первого требования веса и их корреляции с данными спецификации, а затем суммированием результатов. Управление может использовать эти результаты для приоритеты спецификации программного обеспечения.
Конечным результатом SQFD представляет собой набор измеримых технические характеристики продукта и их приоритетов. Haag, Раджа, и Schkade (1996) сообщают, что многочисленные фирмы, которыми они опрошенных понял значительные преимущества от использования SQFD, включая улучшение использования и управления участия, короткий цикл развития, улучшения коммуникации между пользователями и разработчиками, а также улучшение качества в целом. Как можно ожидать, они сообщают, что большинство фирм, использующих SQFD являются те, которые также принимают TQM принципы и процессы в других организационных вопросов.
SQFD это объяснение "Планирование" фазы в знаменитый цикл Shewhart планирования в процессе работы-Проверка-обязанности по повышению качества. Этот цикл был Деминг популяризировал в 1950-х в Японии, где он стал известен как цикл Деминга, и впоследствии экспортировать на Запад. Это бесконечный цикл непрерывного улучшения, который состоит из планирования, делать (экспериментировать с планами, желательно на экспериментальном масштабе), проверка (изучение результатов эксперимента), а также действия (по результатам предыдущих этапов) . Это показано на рисунке 3, как шар проката в гору и повышения уровня качества в этом процессе. По мнению Деминга, руководство должно обеспечить энергией (и направление) для подвижного мяч в гору.
[Рисунок 3 ИЛЛЮСТРАЦИЯ опущены]
Capability Maturity Model (СММ), как показано на рисунке 4, представляет собой рамки, основанные на принципах TQM для улучшения всего процесса разработки программного обеспечения. Он также отражает мнение Кросби (1976) и других, что улучшение качества состоит из эволюционных шагов, а не революционные. Таким образом, пять уровней зрелости СММ в последовательно более продвинутые слои для создания постоянного улучшения в процесс разработки программного обеспечения.
[Рисунок 4 ИЛЛЮСТРАЦИЯ опущены]
Помещение ШМ является то, что процесс способность фирмы находит свое отражение в какой степени она планов и контроля качества программного обеспечения и удовлетворенности клиентов. Эта возможность совершенствования и получает больше структуру, как и фирма созревает с точки зрения управления разработки программного обеспечения. Малый запуска разработчики программного обеспечения зачастую не имеют установившиеся процессы, поэтому первоначальное использование кода и захода на посадку-очень часто. В более зрелые компании, планирования и управленческой практики осуществления, а также процессов развития стали более четко определены и понятны. Например, конкретные метрики могут быть использованы для предоставления объективной обратной связи по программным продуктам в процессе разработки и после родов для клиентов. Эти меры применяются не только судить качество продукции, но и отслеживать удовлетворенность клиентов, выявление дефектов или других связанных с продуктами обратной связи клиентов. Отслеживание и анализ таких данных позволяет фирме внести необходимые изменения в процессах разработки программного обеспечения и повышения качества. Оценки проекта расписания и бюджета, вероятно, будет основано на конкретной информации. Проекты, более вероятно, будет завершено в срок и в рамках бюджета, с их планируется функциональности и ожидаемого уровня качества. В своей книге "Дорога в будущее (1995), Билл Гейтс описывает, каким образом Microsoft использует этот процесс в масштабе всей организации, а также важность призовые места управления на этом аспекте бизнеса.
В СММ, процесс возможностей компании, предусмотренных в плане пять более высоких уровней зрелости:
Уровень 1 (По умолчанию). Немного процессы определяются или документально, а также специальных управление является движущей силой. Успех зависит от индивидуальных усилий. SEI оценкам колоссальные 76 процентов от стоимости всех IS отделы на этом уровне!
Уровень 2 (Повторяется). Проект методов и механизмов управления осуществляется для планирования, отслеживания затрат, сроков и качества. Разработка программного обеспечения и развития стали повторяется. SEI оценкам 15 процентов от стоимости всех IS отделы на этом уровне.
Уровень 3 (определена). Все проекты использования организованной, задокументированы и стандартный набор мероприятий, которые осуществляются на протяжении всего цикла жизни проекта. SEI считает, что лишь 8 процентов от стоимости всех IS отделы на этом уровне.
Уровень 4 (Managed). Конкретные процесс и качество результатов меры осуществляются. Подробные данные об этих мерах регулярно собираться и использоваться для управления всеми проектами. SEI оценкам, менее 1 процента всех IS отделы на этом уровне.
Уровень 5 (оптимизированная). Непрерывное совершенствование процесса на месте во всей организации. Сложные методы профилактики дефектов (таких, как автоматический сбор данных и отчетность), технологии управления изменениями и управления процессом изменения реализованы. Менее 1 процента всех отделов IS, по оценкам, на этом уровне.
СММ стала популярной моделью для оценки организационного потенциала для достижения высокого качества разработки программного обеспечения. В общем, это показывает, как программное обеспечение организации развиваться и становиться в состоянии ответить на вопрос Деминга, "Каким способом?" Это может быть общее руководство для процесса фирмы усилий по совершенствованию, хотя фирма, вероятно, не вписывается ни в заданном уровне именно в данный момент времени. Помимо того, что разумные на логических основаниях, есть эмпирические доказательства того, что улучшения в ключевых практик ШМ может улучшить качество программного обеспечения. Исследование совместной работы показал, что уточнения и координации деятельности, разработки программного обеспечения повышает эффективность проектных групп. Хотя SEI недавно адаптировал оригинальный КММ я к "Люди СММ", который конкретно занимается человек процессов, это не так известны, как оригинальная модель процесса.
Закон Мура применительно к компьютерной техники говорит, что количество вычислительной мощности на один доллар можно купить удваивается каждые 18 месяцев. Говоря другими словами, стоимость фиксированная сумма в размере вычислительную мощность сокращается вдвое каждые 18 месяцев. Предполагая, закон Мура имеет как он в течение последних 30 лет, типичный настольный компьютер в 2000 году будет иметь 800 МГц процессор чип, 128 Мб RAM, 12-гигабайтный жесткий диск, и ценой около $ 1800, в том числе точной цветной монитор. Учитывая недавний опыт более быстрого улучшения в аппаратных технологий, закон Мура, возможно, даже быть пересмотрены в сторону понижения, а также порядок, возможно, 12 месяцев.
Тем не менее, аппаратные улучшения является вторичным по важное значение для улучшения качества программного обеспечения. Нет программного обеспечения может оставаться застой и успешных в то же время, даже если он изначально очень высокого качества. Речь идет о явлении в Интернете, которая в основном состоит из программного обеспечения, а не оборудования (серверного программного обеспечения, браузеры, программы обеспечения безопасности, программное обеспечение присутствия усиление, и так далее). Успех в Интернете - и в информационном рынке в целом - гораздо большей степени зависит программного обеспечения, чем с аппаратным обеспечением.
Верховая езда волны взрыва технологий является отличительной чертой исключительных успехов. Кроме того, в противном случае, чтобы захватить и бежать с ним может означать гибель. IBM ехал волна мэйнфреймов, но не поступает многообещающий рынок программного обеспечения PC, несмотря на то изобрел компьютер. Ван успешно осуществили переход от расчета на рынке нишу для обработки текста, но не смог увидеть свою очередь, по направлению к ПК. И несколько других, видел видение Билла Гейтса о необходимости для обеспечения совместимости и взаимозаменяемости продукции программного обеспечения - следовательно, преобладание MS-DOS, а затем и Windows операционных систем.
В начале 1990-х, Microsoft была, по мнению многих, не заметили лодку на интернет, потому что его внимание на программное обеспечение, предназначенное для человека "не связанных" ПК. Тем не менее компании удалось повернуть лодку, быстро становится одной из основных сил в сфере Интернета. Наличие ресурсов, налить в поворот, конечно, не больно, но средств не помогло бы без верхней зрения управления. В конце концов, имея ресурсов, не помогло IBM и управления ею в 1980-х. Microsoft успешно сегодня, потому что, по большому счету, он имеет более качественные продукты, чем ее конкуренты, его руководство, похоже, принял философия качества и осуществлять качественные программы в рамках всей организации. Если и когда это уже не правда, Microsoft будет наблюдаться сокращение как и IBM, независимо от того, насколько велика ее доли на рынке.
В гонке на рынке программного обеспечения, путь к успеху, безусловно, проходят через области качества. Мы убеждены в том, что победители будут возглавляют люди, которые приняли философию качества и приобрели системы глубокие знания выступают Деминг.
Ссылки
P.B. Crosby, качества Is Free (New York: McGraw-Hill, 1976).
W.E. Деминг, Новая экономика (Cambridge, MA: Массачусетский технологический институт, Центр перспективных исследований инженерия, 1994).
W.E. Деминг, выхода из кризиса (Cambridge, MA: Массачусетский технологический институт, Центр перспективных инженерных исследований, 1982).
Б. Гейтс, Дорога в будущее (Нью-Йорк: Penguin, 1995).
PJ Гвинан, J. Cooprider, С. Фарадж, "Inside" Черный ящик ": Изучение процессов Группы высокого исполнительского Software Design Команды," Информационные системы исследований, готовится.
Фондовая биржа Haag и П. Хоган, "Научно-исследовательский Вопросы обеспечения качества Функция Развертывание: Новое начало для методологии Software Engineering," Труды Института Decision Sciences '92 в Атланте, Джорджия, 1992, с. 926-928.
Фондовая биржа Haag, M.K. Раджа, Л. Л. Schkade, "Quality Использование функции развертывания в разработку программного обеспечения," Сообщения ACM, 39 (1996): 41-49.
JR Хаузер, Д. Клаузинг, "Дом Качества", Harvard Business Review, 66, 3 (1988): 63-73.
W.S. Хамфри, управляющий Программное обеспечение процесса (чтение, М.: Addison-Wesley, 1989).
D. Инс, Введение в Software Assurance качества и ее реализация (New York: McGraw-Hill, 1994).
Н. Негропонте, Being Digital (New York: Vintage Books, 1996).
F. Niederman, JC Бранчо и JC Wetherbe, "Информационные системы управления для 1990-х годов", MIS Quarterly, 15, 4 (1991): 474-500.
Конферансье Полк, C.V. Вебер, С. Гарсия, M.B. Chrissis, М. Буш, Capability Maturity Model программного обеспечения ", CMU/SEI-93-TR-24, Карнеги-Меллон университет, Институт инженерии программного обеспечения, Питсбург, штат Пенсильвания, 1993 (а).
Конферансье Полк, C.V. Вебер, С. Гарсия, M.B. Chrissis, М. Буш, "Ключевые практики Модель зрелости Capability," CMU/SEI-93-TR-25, Карнеги-Меллон университет, Институт инженерии программного обеспечения, Питсбург, штат Пенсильвания, 1993 (б).
Л. Салливан, "Quality функции развертывания," Quality Прогресс, 19, 6 (1986): 39-50.
Г. Тагути и Д. Клаузинг, "Надежность Качество", Harvard Business Review, 68, 1 (1990): 65-75.
В цитированном месте Туроу, голова к голове - грядущему экономическому Битва Среди Японии, Европы и Америки (Нью-Йорк: Уильям Морроу и К °, 1992).
Х. ван де Вен, Л. Delbecq, Р. Кининг, "Детерминанты координации режимов в организациях," American Sociological Review, 41 (1976): 322-338.
Н. Уиттен, управляющий Разработка проектов (Нью-Йорк: Wiley, 1995).
MR Йылмаз является доцент решение наук и Sangit Чаттерджи, профессор статистики, как на Северо-Восточного университета в Бостоне, штат Массачусетс.
