Проектирование и тестирование. Техническое проектированиедетализирует то, как с-мы будет удовлетворять информ-е потребности, выявленные при анализе с-мы.
Технический проект– модель с-мы. Он содержит все спецификации, касающиеся параметров с-мы и её структуры.
Разрабатываются спецификации всех функций, кот-я должна выполнять с-ма.
Процесс проектирования осущ-ся системными проектировщиками и обязательно должно контролироваться пользователям.
Рабочее проектирование заключается в создании спецификации для каждой программной компоненты, входящие в ИС.
Программные компоненты приобретаются у сторонних организаций или создаются в самом п/п.
Тестирование– это тщательный и всесторонний процесс, позволяющий опред-ть готовность с-мы к работе. Это медленный процесс. На этом этапе высокая вероятность выявления ошибок.
Процесс тестирования м.б. разбит на 3 этапа:
1) тестир-е отдельных компонент
2) тест-е всей системы
3) приёмочные испытания.
Конверсия. Эксплуатация и техническое обслуживание.
Конверсия– это процесс перехода со старой с-мы на новую.
Следует иметь ы ыиду, что внедрение информ-й системы оказывает влияние на распределение заданий, структуру п/п и на его сотрудников.
Технологич-е изменения испытывают сопротивление со стороны организ-й структуры и их сотруд-в.
В целом распред-е задания, технологий, модели и орг. Структура взаимосвязаны и влияют друг на друга. Поэтому конверсия – крайне важный этап.
Сущ-т 4 основные стратегии конверсии:
1) Параллельная
2) стратегия прямого переключения
3) Пилотная (опытная)
4) фазовая (поэтапная)
При исполь-и параллельной стратегииновая с-мы запускается при одновременно работающей старой системе. Обе ИС работают до тех пор, пока не станет ясным, что новая с-ма функционирует правильно.
Это безопасный и консервативный подход, однако, он может привести к большим затратам и необходимость содержать доп-й персонал для обслуживания ещё одной системы.
Стратегия прямого переключенияпредполагает полную замену старой с-мы на новую в опред-й день.
Согласно этой стратегии единств-й способ произвести изменения заключается в одновременном обновлении технологий, распределения заданий, структуры п/п и сотрудников.
Иногда даже используют концепцию снятия контроля орг-ии перед внедрением новой технологии (концепция «размораживания»). После этого следует быстрое внедрение новой с-мы и «замораживание» п/п.
Стратегия прямого переключения может оказаться менее дорогостоящий, чем параллельная, однако, этот подход связан с большим риском и может привести к значительным затратам в случае возникновения проблем с новой с-мой.
Пилотная (опытная) стратегия.Заключается во внедрении новой с-мы отдельными функциями, частями одна за другой.
Нередко совмещают с пилотной стратегией.
Конверсия заканчивается написание окончат-го варианта документации, кот-я используется в дальнейщем.
Эксплуатация – период стабильного функционирования ИС.
На этом этапе проводится проверка работы с-мы как пользователями, так и технич-м персоналом и накапливается инф-я об изменениях, кот-я необходимо внести в с-му.
В прцессе технич-го обслуж-я происходит внесение изменений в оборуд-е, программное обеспечение, документацию и т.д. для повышения эффект-ти работы с-мы или при появлении новых требований. Объем работ по обслуживанию существенно зависит от кач-ва выполнения всех предыдущих работ.
Методы создания ИС.
При планировании, разработке новой ИС, в первую очередь необходимо изучить следующие факторы:
1) окружение, в кот-м протекает деят-ть орг-ии;
2) структура орг-ии (иерархия, специализация, стандартные порядки действия);
3) культура и политика орг-ии;
4) тип орг-ии;
5) основные принципы рук-ва;
6) состав и структура высшего рук-ва орг-ии;
7) внешние с-мы на внутр-е подгруппы коллетива п/п;
8) виды задач, решений и БП, для поддержки кот-х предназначены ИС;
9) настроение работников и их отношение к внедрению новой ИС;
10) история развития орг-ии.
Для создания ИС применяются различные методики:
1) Методология жизненного цикла;
2) создание с-мы с пом-ю прототипа
3) разработка с пом-ю пакетов прикладных программ.
4) разработка конечными пользователями
5) разработка сторонними орг-ми (аутсорсинг)
Методология жизненного цикла системы
Жизненный цикл системы– методика разработки Ис, разделяющая процесс на отдельные последоват-е стадии (предпроект-е обследования, проект-е и т.д.), в кот-х используют четкое разделение труда между конечными пользователями и разработчиками.
Это методика используется при создании сложных проектов крупного масштаба.
Специалисты по ИС (системные аналитики, программисты и т.д.) проводят осн. Ситемный анализ проектирования и внедрения с-мы, а пользователи занимаются выяснением информационных потребностей и оценкой работы технич-го персонала.
К настоящему времени наибольшее распространение получили след-е модели жизненного цикла:
Каскадная
Спиральная
Использование каскадной модели предполагает, что весь процесс проектирования разбивается на этапы т.о., что переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем этапе.
При этом каждый этап завершается выпуском полного комплекта документации достаточной для того, чтобы разработка м.б. продолжена другой командой разработчиков.
«+» такого подхода заключается в том, что:
1) на каждом этапе формир-ся законченный набор проектной документации)
2) выполняемые этапы работ облегчают планир-е сроков завершения всех работ и соотв-х затрат.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для кот-х в самом начале разработки точно и полно сформулированы все требования.
“-“ (основной):
1) существ-е запаздывание с получением рез-та.
Согласование рез-в производится только после завершения каждого этапа работ. Требования к с-ме зафиксированы на всё время её создания. Пользователи могут свои замечания только после того, как работа под с-мой будет полностью завершена.
При использовании спиральной модели упор делается на начальные этапы (анализ и проектирование).
На этих этапах реализуемость решений проверяется путём создания работников м в случае необходимости производится возврат на предыдущий этап.
Т.о., углубляются и последовательно конкретизируются детали проекта. В результате выбирается обоснованный вариант, кот-й и доводится и до реализации.
Неполное завершение работ на каждом этапе позволяет переходить на след-й этап до полного завершения работы на текущем этапе.
Главная задача – как можно быстрее показать пользователям с-мы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Осн-я проблема этой методики – определение момента перехода на след-й этап. Переход осущ-ся в соотв-и с планом, даже если не вся запланированная работа выполнена.
В целом, следует иметь в виду, что методология жизненного цикла сопряжена с большими финанс-ми затратами, требует больших временных затрат и не отличается гибкостью.
|