Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Понимание необходимости их адаптации (кастомизации) часто возникает в конце, когда происходит полноценное тестирование, а свободных ресурсов уже нет




Разработка ИС с помощью прототипирования

Самые дорогие ошибки — это ошибки, допущенные в начале проекта, так как именно на начальных этапах принимаются наиболее важные решения.

По мере развития проекта, стоимость ошибки снижается.

В то же время, начальный уровень контроля качества является минимальным и повышается по мере продвижения процесса разработки. Полноценное тестирование начинается только на поздних этапах.

Результатом часто является слишком позднее выявление самых дорогих ошибок и последующая дорогостоящая переработка системы либо ее отдельных частей. На первый взгляд может показаться, что некоторые проекты одинаковы по своей сути и содержанию. Скажем, типовым проектом для вас является интернет-магазин на базе существующей у вас системы. Но индивидуальность каждого проекта заложена даже в самом его определении.

Бытует мнение о том, что разработка однотипных проектов (например, создание интернет – магазинов) может проходить без этапа проектирования. Можно разделить задачу проектирования на создание типовых стандартных решений, которые кочуют из проекта в проект и творческие задачи, которые необходимо решать в каждом новом проекте.

Очевидно, что пользователи интернет-магазина по продаже удобрения и сельскохозяйственной техники будут сильно отличаться от пользователей магазина по продаже одежды и гламурных аксессуаров, как и будет отличаться их поведение на сайте, объекты внимания и т.д. Способно ли ваше стандартное решение учесть различия пользователей?

Стандартное решение — это набор компонентов, оттестированных и опробованных в различных проектах.

Это и есть та самая дорогая ошибка (перерасход проектного времени, приводящий к авралу, ухудшение качества). Парадокс новой экономики, о которой написал Купер — чтобы сэкономить, нужно заплатить (инвестировав в проектирование).

Любая создаваемая интегрированная система должна включать значительное количество объектов, обрабатывать большой объем информации и запросов в приемлемые сроки. Именно поэтому обоснованная выработка концепции построения системы требует проведения моделирования процессов, протекающих в реальной системе, и реализации МАКЕТА системы, на котором могут быть смоделированы наиболее важные свойства разрабатываемой системы, в том числе и альтернативные.

С учетом сложности, распределённости и разнообразия задач, для решения которых предназначается МАКЕТ, его системная среда функционирования должна удовлетворять следующим требованиям:

· открытость и переносимость, упрощающие адаптацию к требованиям конкретного потребителя и обеспечивающие наращивание функциональной и интеллектуальной мощности в процессе эксплуатации без тотального перепрограммирования, т. е. в кратчайшие сроки и с минимальными затратами на разработку и сопровождение;

· быстрая разработка приложений за счет интеграции в программную среду современных технологий: объектно-ориентированного подхода, технологии экспертных систем, CASE-технологии, имитационного моделирования, средств быстрой разработки приложений;

· хранение значительных объемов данных и оперативный доступ к ним.

Рассмотрение взаимодействия даже небольшого количества объектов управления во времени и пространстве настолько повышает сложность практически значимых задач, что традиционные технологии и средства программирования мало пригодны для их решения. Недостатки традиционного подхода к созданию программных продуктов, состоящего из пяти последовательных этапов (анализ, проектирование, программирование, тестирование и интеграция), общеизвестны:

· лавинообразное нарастание сложности,

· непригодность для разработки сложных программных систем реального времени,

· высокая стоимость внесения в систему последующих изменений,

· обязательное последовательное выполнение всех этапов разработки,

· несовместимость с эволюционным подходом и перспективными методами разработки.

Кроме того, при разработке большой и сложной системы, зачастую невозможно сформулировать строгие, детальные спецификации окончательного программного продукта на этапе анализа из-за инновационного характера разрабатываемой системы.

Проблемы создания МАКЕТА связаны с преодолением следующего ряда трудностей объективного характера:

1) высокая стоимость ошибок, которые могут быть допущены на ранних стадиях проектирования МАКЕТА, когда в будущую систему закладываются основные требования и определяются спецификации ее работы в действующей организационно-технологической среде;

2) неприемлемость длительной разработки программно-информационного обеспечения МАКЕТА, поскольку исходные требования к системе за это время могут существенно трансформироваться;

3) необходимость адекватной оценки эксплуатационных характеристик МАКЕТА и проверки удовлетворения требований к нему еще до окончательной реализации всего МАКЕТА, т.к. затраты на переделку сложной системы могут выходить за рамки финансовых ограничений;

4) необходимость и высокая трудоемкость моделирования процессов принятия решений с учетом всех особенностей решаемых задач;

5) принципиальная необходимость создания наращиваемого, развиваемого и переносимого программного продукта, жизненный цикл которого не должен заканчиваться с первыми сколько-нибудь существенными изменениями технологии работы, требований пользователей (требования пользователя ИМЕЮТ ПРАВО изменяться) и обновлением вычислительной базы;

6) минимизация количества несовместимых альтернативных программных платформ и инструментальных средств, используемых при создании МАКЕТА, поскольку в противном случае его будет слишком дорого либо невозможно сопровождать.




Поделиться с друзьями:


Дата добавления: 2014-01-13; Просмотров: 398; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.014 сек.