-
Notifications
You must be signed in to change notification settings - Fork 7
exam05 6
Выполнила Маслова Яна, ИДБ-18-07
Проблема (Problem) - неизвестная причина одного или более инцидентов
Любая проблема представляет собой сложный вопрос теоретического или практического характера, который требует изучения и разрешения. В научной трактовке проблема представляет собой противоречивую ситуацию, обусловленную взаимоисключающими позициями в объяснении процессов, объектов или явлений. В обычной же жизни проблему можно сформулировать как ситуацию, когда понятно, что нужно получить, но непонятно, как этого добиться.
- Недоказуемость нереалистичности бюджета и сроков.
Разработчик ИС не в состоянии предоставить руководителю, заказчику или специалисту по сбыту достаточно обоснованные доказательства нереалистичности предложенного бюджета и сроков. Результат - оптимистичная переоценка выгод собственной разработки, недооценка роли других конкурирующих предложений о заключении контрактов на разработку ИС и, вследствие всего этого, — неизбежные перерасходы и ухудшение качества разрабатываемой системы.
- Несбалансированность программных и технических средств.
Системные аналитики при проектировании ИС не в состоянии выполнить достаточно обоснованный реалистичный анализ компромиссов программно-технических решений. Результат - появление проектов, в которых затраты на технические средства необоснованно уменьшены за счет более значительного увеличения затрат на программное обеспечение.
- Необоснованность сроков разработки и затрат труда.
Руководители проекта не в состоянии достаточно обоснованно определить, сколько времени и какие затраты труда потребуются на каждую фазу программной части проекта.
- Несовершенство постановочной части проекта.
Техническое задание ограниченного объема дает лишь приблизительные направления реализации, практически включая лишь нормативы технических характеристик ИС. Попытка разработать на этапе постановки более или менее детальную спецификацию системы влечет катастрофическое возрастание объемов работ, а в силу необходимости многочисленных согласований разрабатываемых документов возможности использования специального инструментария ограничены. На практике, как правило, ограничиваются «разумным» объемом спецификаций, оставляя детальное согласование спецификаций «на потом». Известна завершающая фраза большинства технических заданий «.. .данное техническое задание может уточняться и дополняться». Никто не может дать гарантии, что все положения технического задания будут реализованы, возможно ли это принципиально и, более того, что для реализации конкретного требования будут приложены достаточные усилия.
- Сложность управления разработкой большого проекта.
Большой коллектив исполнителей требует декомпозиции проекта на подсистемы для групп исполнителей, формирование индивидуальных заданий и формулирование спецификаций на них, включая требования к их функциональному тестированию, а также контроль исполнения, обеспечение автономного и комплексного тестирования, поддержка внутригруппового документооборота. Все было бы не так грустно, если бы качество выполнения этой работы поддавалось контролю. Фактически, на каждом шаге декомпозиции осуществляется неконтролируемая интерпретация проектных данных. При сборке готовых частей эти интерпретации проверяются на совместимость, что, при отрицательном результате, с неизбежностью вызывает итерационный процесс перепроектирования.
- Документирование.
Программная документация, составляемая исполнителями, страдает несколькими недостатками: неполнота - часть информации остается вне ее в связи либо с трудностями ее формализации, либо с ее объемом; несоответствие текущей версии проекта; большая трудоемкость; использование ее как отчетного, но не рабочего материала.
- Тестирование.
Наибольшие трудности для тестирования представляют не концептуальные ошибки в структуре программы или в описании потоков управления и данных, довольно быстро обнаруживаемых функциональными тестами на этапе автономной отладки, а составляющие основную массу «описки», неточно интерпретируемые спецификации и некорректные взаимодействия между элементами программы. Естественно, последние связаны с «человеческим фактором» происхождения теста программ. Для их устранения не существует других способов, кроме создания «полных» тестов на программы, активизирующих все ветви программного кода с обеспечением «наблюдаемости» этой активизации. Создание таких тестов принципиально возможно только при серьезных ограничениях на структуру разрабатываемого программного кода, само по себе чрезвычайно трудоемко, не гарантирует приемлемый результат и поэтому в реальной жизни не практикуется.
- Авторское сопровождение.
Несмотря на большие усилия, прилагаемые для документирования проекта, реально сопровождать готовый проект, устраняя ошибки, замечания и дорабатывая программное обеспечение в процессе внедрения, способен только коллектив разработчиков. Как следствие, судьба проекта целиком зависит как от способности разработчиков качественно поддерживать жизненный цикл ИС, так и от способности коллектива существовать продолжительное время в новом качестве («испытание внедрением»). Перечисленные проблемы можно наглядно проиллюстрировать на примере проекта по созданию оперативной системы управления, реализованной для ВВС США. Оценку стоимости ИС осуществляют с помощью так называемых моделей. Модель считается хорошей, если с ее помощью можно оценить затраты на разработку ИС с точностью до 20 % в 70 % случаев.
Обходной путь-это обход признанной проблемы или ограничения в системе или политике. Обходной путь, как правило, представляет собой временное исправление, которое подразумевает, что необходимо подлинное решение проблемы. Но обходные пути часто столь же креативны, как и истинные решения, предполагающие нестандартное мышление при их создании.
Как правило, они считаются хрупкими потому что они плохо реагируют на дальнейшее давление со стороны системы, выходящей за рамки первоначальной конструкции. При реализации обходного пути важно отметить изменение, чтобы впоследствии реализовать правильное решение.
Запла́тка, или патч (англ. patch /pætʃ/ — заплатка) — информация, предназначенная для автоматизированного внесения определённых изменений в компьютерные файлы. Применение патча иногда называется «пропатчиванием».
Патчем или обновлением (англ. update) называется, в частности, содержащее такую информацию автоматизированное отдельно поставляемое программное средство, используемое для устранения проблем в программном обеспечении или изменения его функциональности.
Исправление может применяться к уже установленной программе, либо к её исходным кодам. Сюда входит исправление ошибок, изменение внешнего вида, улучшение эргономичности или производительности программ, а также любые другие изменения, которые разработчик пожелал сделать.
Размер патчей может варьироваться от нескольких килобайт до сотен мегабайт. В частности, очень большими патчи могут быть при изменении или замене непрограммных данных, таких как файлы с графикой и звуком (часто встречаются в компьютерных играх). Тем не менее, большой размер может быть вызван и многочисленностью вносимых изменений. При этом слова «патч», «заплатка» обычно используются для обозначения небольших исправлений, большие же патчи, серьёзно меняющие или обновляющие программу, часто называются «service pack» или «software updates».