Выбор технологий и стандартов при разработке системы решение, определяющее успех применения системы, возможности реинжиниринга, срок службы, переход впоследствии на новые более прогрессивные технологии.
Термин «реинжиниринг» был введен ведущими американскими специалистами в области консалтинга Майклом Хаммером (Michael Hammer) и Джеймсом Чампи (James Champy).
Реинжиниринг - это перестройка (перепроектирование) деловых процессов для достижения радикального, скачкообразного улучшения деятельности фирмы. Это - комплексное изменение действующих бизнес процедур и перепланирование операций, направленное на кардинальное снижение затрат, повышение качества продукции и более полное удовлетворение запросов потребителей.
Квалифицированные разработчики ИС ориентируются на стандарты открытых систем. Открытыми называются системы, которые могут развиваться за счет технических и/ или программных средств, созданных на основе технологии, удовлетворяющих требованиям международных стандартов. Главное преимущество открытых систем в том, что они обеспечивают интероперабельность технических и программных средств различных производителей, то есть совместное их использование в едином проекте. Следование стандартам позволяет обеспечить интероперабельность как системных компонентов, так и различных взаимодействующих систем, межплатформенную совместимость программного обеспечения, приложений и данных в технологиях баз данных и т.д.
Существуют стандарты на операционные системы, языки программирования, сетевые протоколы и т.д. Для достижения совместимости следует использовать минимальный набор стандартных средств. Отсутствуют стандарты на наиболее современные и продвинутые решения (их не успевают стандартизировать).
1.
Понятие жизненного цикла ИС. Этапы проектирования
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:
каскадная модель (70-85 г.г.);
спиральная модель (86-90 г.г.).
Использование каскадной модели ЖЦ предполагает, что весь процесс проектирования разбивается на этапы. Переход с одного этапа на следующий этап происходит только после того, как будет полностью завершена работа на текущем этапе. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
· на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
· выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. Однако что реальный процесс создания ИС редко умещался в заданную схему, зачастую возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений.
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС зафиксированы на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ИС, пользователи получают систему, не удовлетворяющую их потребностям. Модели автоматизируемого объекта могут устареть одновременно с их утверждением.
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов.Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, до полного завершения работы на текущем этапе. При таком подходе недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований
Перейти на страницу:
1 2 3
