Кто-либо все еще верит в Модель технологической зрелости для программного обеспечения?
Когда вы объявляете ссылочную переменную (т. е. объект), вы действительно создаете указатель на объект. Рассмотрим следующий код, в котором вы объявляете переменную примитивного типа int:
int x;
x = 10;
В этом примере переменная x является int, и Java инициализирует ее для 0. Когда вы назначаете его 10 во второй строке, ваше значение 10 записывается в ячейку памяти, на которую указывает x.
Но когда вы пытаетесь объявить ссылочный тип, произойдет что-то другое. Возьмите следующий код:
Integer num;
num = new Integer(10);
Первая строка объявляет переменную с именем num, но она не содержит примитивного значения. Вместо этого он содержит указатель (потому что тип Integer является ссылочным типом). Поскольку вы еще не указали, что указать на Java, он устанавливает значение null, что означает «Я ничего не указываю».
Во второй строке ключевое слово new используется для создания экземпляра (или создания ) объекту типа Integer и переменной указателя num присваивается этот объект. Теперь вы можете ссылаться на объект, используя оператор разыменования . (точка).
Exception, о котором вы просили, возникает, когда вы объявляете переменную, но не создавали объект. Если вы попытаетесь разыменовать num. Перед созданием объекта вы получите NullPointerException. В самых тривиальных случаях компилятор поймает проблему и сообщит вам, что «num не может быть инициализирован», но иногда вы пишете код, который непосредственно не создает объект.
Например, вы можете имеют следующий метод:
public void doSomething(SomeObject obj) {
//do something to obj
}
В этом случае вы не создаете объект obj, скорее предполагая, что он был создан до вызова метода doSomething. К сожалению, этот метод можно вызвать следующим образом:
doSomething(null);
В этом случае obj имеет значение null. Если метод предназначен для того, чтобы что-то сделать для переданного объекта, целесообразно бросить NullPointerException, потому что это ошибка программиста, и программисту понадобится эта информация для целей отладки.
Альтернативно, там могут быть случаи, когда цель метода заключается не только в том, чтобы работать с переданным в объекте, и поэтому нулевой параметр может быть приемлемым. В этом случае вам нужно будет проверить нулевой параметр и вести себя по-другому. Вы также должны объяснить это в документации. Например, doSomething может быть записано как:
/**
* @param obj An optional foo for ____. May be null, in which case
* the result will be ____.
*/
public void doSomething(SomeObject obj) {
if(obj != null) {
//do something
} else {
//do something else
}
}
Наконец, Как определить исключение & amp; причина использования Трассировки стека
20 ответов
Для типичного центра программирования уровня 1 CMM, прилагая усилие для получения до уровня 2 стоит; это означает, что необходимо думать о Вас процессы и записать их. Естественно, это встретит сопротивление от программистов ковбоя, которые чувствуют себя ограниченными стандартами, документацией и тестовыми сценариями.
усилие добраться от уровня 2 ("существует процесс") к уровню 3 ("у всех есть тот же процесс") обычно увязает в межведомственной войне, таким образом, это, вероятно, не стоит запустить.
Существует довольно много хороших идей, которые могут с готовностью быть адаптированы и приняты любой организацией по их собственной пользе, но получение значка является болью из-за требования для всех видов избыточной документации.
проблема состоит в том, что CMMi не является процессом, но просто руководством для любого процесса, который Вы могли бы принять решение иметь и который сам по себе приглашает непродуманные идеи, текущие вокруг.
Другая точка - то, что миграция является реальной болью, когда Вы запускаете, но она совпадает с любой другой начинающейся проблемой, я предполагаю.
Меньшие проекты являются меньшим количеством иждивенца на процессе для успеха. Ключевая метрика является Героем к Отношению Свидетеля. Любой проект с HTBR меньше чем 0,2 находится в серьезной проблеме.
Когда я работал над коммерческим программным обеспечением полета, мы использовали CMM и поскольку наши процессы улучшили нашу способность точно предсказать улучшенные времена завершения. Но это было громоздким процессом, другие подходы должны работать точно также.
Гибкий следующий CMM, и оба хрупки. Поле процесса и качественного консалтинга является хорошим бизнесом в любой промышленности, и как технические люди всем нужны новые модные словечки для хранения денежного течения.
CMM, когда это сначала вышло из SEI, был пользой, основанной на понятиях на серьезной научной работе, но это было скоро взято консультантами по процессу и является бесполезной сертификацией теперь, которая используется большей частью CIOs для покрытия их задницы (Никто не был уволен за выбор компании Уровня 5 CMM)
Гибкий, собирается спуститься по тому маршруту скоро, и затем мы, несомненно, сможем видеть следующую серебряную пулю в горизонте скоро:)
Я привык для. Но теперь я нахожу, что CMM и CMMI действительно не оснащают это хорошо гибкими подходами.
Ну конечно можно сжать вещи получить тот квадратный штепсель в круглую дыру, но когда нажатие прибывает в толчок, Вы все еще основываете свой подход к способности предсказать все, что необходимо, и предупреждение всего, с чем встретятся при создании программной системы.
И все мы знаем, как хорошо, что подход работает в реальной жизни! (-:
аплодисменты,
Rob
В школе мне преподавали: CMM является хорошая Идея, но недостающая сертификация (любой может сказать, что они - уровень 5 / уровень 4), это заканчивает тем, что было маркетинговым инструментом для офшорных магазинов. Так, да, идея является звуковой, но как Вы доказываете соблюдение?
Модель проигрывает, это - доверие, сначала потому что компании принимают модель не поиск maturer модели разработки программного обеспечения, но оцениваться к уровню CCMI.
И другая проблема, та, что я думаю, приводит к потерянному доверию, то, что как подрядчик, у Вас нет гарантии, что проект, который Ваш оценочный поставщик CMMI продает Вам, будет разработан с помощью образцовых методов. CMMi маркируют только состояния, что компания когда-то разработала проекты, которые были оценены как адгезивные средства к определенному уровню Зрелости CMMi.
проблема не находится только на CMMi, но и на процессе, разработанном компаниями. CMMi не описывает сам процесс, но что должен сделать процесс. У Вас есть та же проблема с PMBOK. На самом деле проблемой не является просто PMBOK, но и прежде всего проблемой являются плохие менеджеры проектов, которые утверждают, что следовали за операторами PMI.
P.S., Хотя немного вне темы, я хотел бы упомянуть, что фальсифицируемые сертификации CMMI являются очень общими, а также реальными сертификациями, полученными посредством взяточничества.
CMM действительно не говорит с качеством программного обеспечения, но больше к документации и воспроизводимости процесса. Другими словами, возможно иметь организованный и повторяемый процесс разработки, но все еще создать дрянное программное обеспечение. Пока процесс правильно документируется, возможно достигнуть Уровня 5.
CMM В конце дня, CMM является другим инструментом, который может использоваться или неправильно использоваться. Если конечная цель должна улучшить качество программного обеспечения, возможно использовать CMM, чтобы улучшить процесс разработки и улучшить качество программного обеспечения. Если достижение определенного уровня CMM является целью, тогда наиболее вероятное качество программного обеспечения пострадает.
Yourdon все еще верит . Но он мог бы также все еще полагать, что мир собирается закончиться двухтысячным годом.
Это не что-то, с чем я лично вставил бы большую веру или хотел бы быть соединенным скобой в будущем. Но часто наш не должен рассуждать почему...
Все формальные методы существуют для продажи курсов/сертификации книг/обучения, и ни по какой другой причине. Вот почему существует столько формальных методов. Как только Вы понимаете это, Вы - свободный:-)
Я делал большое интервьюирование для малочисленных команд, делающих итерационную разработку. Лично, если я вижу CMM на резюме, это - большой красный флаг, который сигнализирует об интересе к процессу по результатам.
Мой опыт состоит в том, что CMM так неопределенен что его очень легкое для выполнения. Кроме того, когда они прибывают для сертификации Вас, они смотрят на проект, который выбирает Ваша организация. Где я раньше работал, это было проектом без реального крайнего срока, большого количества денег и большого количества времени для расходов на каждый укромный уголок и трещину процесса. Многие из других проектов продолжали мало ни к какому коду/анализу проекта иногда без программного обеспечения управления версиями.
я думаю, что акцент на сертификацию CMM неудачен. Компании знают, как работать система и сделать. Вместо того, чтобы фокусироваться на реальном усовершенствовании процесса, которое встречает их нижнюю строку, они фокусируют на получении сертификации и работе систему. Я честно думаю, что большинство организаций провело бы время на первом вместо того, чтобы тратить впустую так много времени на последнего.
Действительно то, что имеет значение, имеет добросовестных людей, которые хотят принять хорошие решения разработки и знать, что они будут нуждаться в помощи, принимая те решения. Нет никакой замены для качественных программистов, которые знают, что программирование является продолжающимся действием группы, где они так же вероятны сделать ошибку как кто-либо еще.
CMMI не действительно об улучшении Вашего программного обеспечения, это о документировании, что Вы сделали. Можно почти оценить уровень компании CMMI весом документации, которую он производит.
Фон: Я изучил CMMI в своей программе специализации Разработки программного обеспечения и работал над командой, которая следовала ее инструкциям.
Более верхний уровень? Магазины № CMM-5 не производят на меня впечатление.
более низкий уровень? Да. Организации CMM-1 пугают меня.
CMM может помочь новой мере команды / мере команды новичка самостоятельно и сделать сам вещь улучшения.
Если Вы видите выполненный CMM. И выполненный быстро.
CMM и CMMI оба предложения некоторые преимущества, если Ваша организация заражается повреждениями, она пытается преподавать в глубине души. Проблема состоит в том, что получение к более высоким уровням является очень трудным и дорогим, и единственное время, которое я видел, организация пройти усилие - то, потому что их клиенты не позволят им предложить цену за контракты, пока они не будут на определенном уровне.
Это имеет эффект организации, делающей все, что они могут к, "просто получают число", на самом деле не заботясь об этом улучшающий их процесс.
Я нашел, что он был чрезмерно увеличен в размере, осуществление документации, которое использовалось главным образом в качестве contract-acquiring/maintaining механизма. Как только у нас был контракт, тогда это было упражнение в том, чтобы обходить процесс.
Как разработчик, я ничего не вытащил из него кроме потерянных МЕСЯЦЕВ моего профессионального жизненного пукания скрипки вокруг с CMMI.
, то же идет для 6 Сигм, которые я выпустил под брендом "Здравый смысл в Поле". Я не должен был быть обучен, как выяснить то, чем проблема была к процессу - это было обычно довольно очевидно.
Для меня, малочисленные команды и гибкие механизмы работают намного лучше. Короткие циклы, большая коммуникация. Это не могло бы работать во всех средах, но это определенно работает в моем.
Просто мои два цента.
В основе вопроса находится эта проблема, аккуратно описанная самим руководством CMM...
“ ... Звуковое суждение необходимо для использования CMM правильно и с пониманием. Аналитика, опыт и знания должен сформировать соответствующую интерпретацию CMM в определенной среде. Та интерпретация должна быть основана на бизнес-потребностях и целях организации и проектов. Механическое, ориентированное на контрольный список приложение CMM имеет потенциал, чтобы вредить организации, а не помочь ему... ”
От Страницы 14, разделите 1.6 из Модель технологической зрелости, Инструкции для Улучшения Программного процесса Институтом программной инженерии Университета Карнеги-Меллон, ISBN 0-201-54664-7.