Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Основные проблемы, возникающие при создании ИС.Содержание книги
Поиск на нашем сайте
Проблема 1. Недоказуемость нереалистичности бюджета и сроков. Разработчик ИС не в состоянии предоставить руководителю, заказчику или специалисту по сбыту достаточно обоснованные доказательства нереалистичности предложенного бюджета и сроков. Результат - оптимистичная переоценка выгод собственной разработки, недооценка роли других конкурирующих предложений о заключении контрактов на разработку ИС и, вследствие всего этого, — неизбежные перерасходы и ухудшение качества разрабатываемой системы. Проблема 2. Несбалансированность программных и технических средств. Системные аналитики при проектировании ИС не в состоянии выполнить достаточно обоснованный реалистичный анализ компромиссов программно-технических решений. Результат - появление проектов, в которых затраты на технические средства необоснованно уменьшены за счет более значительного увеличения затрат на программное обеспечение. Проблема 3. Необоснованность сроков разработки и затрат труда. Руководители проекта не в состоянии достаточно обоснованно определить, сколько времени и какие затраты труда потребуются на каждую фазу программной части проекта. Проблема 4. Несовершенство постановочной части проекта. Техническое задание ограниченного объема дает лишь приблизительные направления реализации, практически включая лишь нормативы технических характеристик ИС. Попытка разработать на этапе постановки более или менее детальную спецификацию системы влечет катастрофическое возрастание объемов работ, а в силу необходимости многочисленных согласований разрабатываемых документов возможности использования специального инструментария ограничены. На практике, как правило, ограничиваются «разумным» объемом спецификаций, оставляя детальное согласование спецификаций «на потом». Известна завершающая фраза большинства технических заданий «...данное техническое задание может уточняться и дополняться». Никто не может дать гарантии, что все положения технического задания будут реализованы, возможно ли это принципиально и, более того, что для реализации конкретного требования будут приложены достаточные усилия. Проблема 5. Сложность управления разработкой большого проекта. Большой коллектив исполнителей требует декомпозиции проекта на подсистемы для групп исполнителей, формирование индивидуальных заданий и формулирование спецификаций на них, включая требования к их функциональному тестированию, а также контроль исполнения, обеспечение автономного и комплексного тестирования, поддержка внутригруппового документооборота. Все было бы не так грустно, если бы качество выполнения этой работы поддавалось контролю. Фактически, на каждом шаге декомпозиции осуществляется неконтролируемая интерпретация проектных данных. При сборке готовых частей эти интерпретации проверяются на совместимость, что, при отрицательном результате, с неизбежностью вызывает итерационный процесс перепроектирования. Проблема 6. Документирование. Программная документация, составляемая исполнителями, страдает несколькими недостатками: неполнота - часть информации остается вне ее в связи либо с трудностями ее формализации, либо с ее объемом; несоответствие текущей версии проекта; большая трудоемкость; использование ее как отчетного, но не рабочего материала. Проблема 7. Тестирование. Наибольшие трудности для тестирования представляют не концептуальные ошибки в структуре программы или в описании потоков управления и данных, довольно быстро обнаруживаемых функциональными тестами на этапе автономной отладки, а составляющие основную массу «описки», неточно интерпретируемые спецификации и некорректные взаимодействия между элементами программы. Естественно, последние связаны с «человеческим фактором» происхождения теста программ. Для их устранения не существует других способов, кроме создания «полных» тестов на программы, активизирующих все ветви программного кода с обеспечением «наблюдаемости» этой активизации. Создание таких тестов принципиально возможно только при серьезных ограничениях на структуру разрабатываемого программного кода, само по себе чрезвычайно трудоемко, не гарантирует приемлемый результат и поэтому в реальной жизни не практикуется. Проблема 8. Авторское сопровождение. Несмотря на большие усилия, прилагаемые для документирования проекта, реально сопровождать готовый проект, устраняя ошибки, замечания и дорабатывая программное обеспечение в процессе внедрения, способен только коллектив разработчиков. Как следствие, судьба проекта целиком зависит как от способности разработчиков качественно поддерживать жизненный цикл ИС, так и от способности коллектива существовать продолжительное время в новом качестве («испытание внедрением»). Перечисленные проблемы можно наглядно проиллюстрировать на примере проекта по созданию оперативной системы управления, реализованной для ВВС США. Оценку стоимости ИС осуществляют с помощью так называемых моделей. Модель считается хорошей, если с ее помощью можно оценить затраты на разработку ИС с точностью до 20 % в 70 % случаев.
|
||||
Последнее изменение этой страницы: 2017-02-21; просмотров: 1820; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 13.59.97.103 (0.008 с.) |