Файл: "Разработка информационной системы торговой интернет-фирмы".pdf

Рисунок 2

Заказ на разработку у сторонних фирм.

При расмотрении этого варианта мы столкнёмся с таким термином как аутсорсинг.

Что такое аутсорсинг? Каковы преимущества и недостатки аутсорсинга?

Аутсорсинг ИС это:

• заказ информационной системы фирмой-потребителем у фирмы-производителя ИС;
• сдача ИС фирмой-производителем в аренду фирме-потребителю ИС;
• выполнение сторонней фирмой обработки информации для фирмы-потребителя.

Цели аутсорсинга:

• Снижение издержек (правда, более актуально для зарубежных стран, где ставка почасовой оплаты гораздо выше, чем в России);
• При необходимости резкого сокращения срока работ (при высокой загруженности IT-специалистов);
• В случае, если невозможно выполнить задачу силами своих сотрудников;
• Функции и задачи аутсорсинга
• Разработка и внедрение больших информационных систем;
• Консалтинговые услуги (проведение тендеров, поиск партнеров, экспертные оценки, содействие в стратегии развития, подготовка регламентов, ИТ-аудит и т.п.);
• Обслуживание и ремонт компьютерной и серверной техники;
• Телекоммуникационные услуги;
• Поддержка локальных сетей;
• Обслуживание телефонного и офисного оборудования;
• Развитие информационной безопасности;
• Поддержку дорогостоящих с точки зрения ИТ бизнес-процессов (процессинг, выпуск пластиковых карт);

Преимуществами аутсорсинга ИС являются:

• Возможность сфокусировать внимание компании на ее основном бизнесе;
• Возможность гибко реагировать на изменения на рынке и внутри компании;
• Отсутствие необходимости в расширении штата компании;
• Сокращение затрат на операции.

Недостатками аутсорсинга ИС являются:

• Возможность потери поставщика (надежность)

Ниже приведем примеры поставщиков и список предлагаемых услуг и их цен:

1. Сайт mainapp.pro предлагает разработку мобильных предложения для интернет-магазина(см. рис. 3):

Рисунок 3

1. Сайт p-gp.ru предлагает дешевые готовые решения сайтов интернет-магазинов и сайтов-визиток(см. рис. 4 и рис. 5):

Рисунок 4

Рисунок 5

1. Сайт webtu.ru предлагает разработку сайтов, доработку и готовые решения(см. рис. 6):

Рисунок 6

Что стоит знать о разработке ИС?

Процесс разработки ИС.

• Определение требований. Разработка любой системы начинается с постановки задачи. ИС, как правило, создается для большого количества пользователей. Каждый из них предъявляет собственные требования к системе. На этом этапе необходимо выявить всех потенциальных пользователей ИС, и для каждого из них составить список требований к ней. Так будут сформулированы основные функциональные требования к системе.
• Этап анализа. Аналитическая модель структурирует функциональные требования к системе. Она описывает уже внутренний вид системы, используя язык разработчиков. Она представляет собой анализ каждого варианта использования и определяет его дальнейшую реализацию.
• Этап проектирования. Это самый трудоемкий этап разработки информационной системы. На данном этапе необходимо разработать проекционную модель всей системы в целом и каждого из ее блоков. Для каждой задачи, которая будет реализована в рамках системы, необходимо описать возможные методы ее решения. Эти методы следует сравнить между собой по критериям, значимым с точки зрения системы, на основании чего выбрать лучший из них. Именно этот метод должен быть реализован впоследствии в программе. Также на этом этапе происходит проектирование базы данных. Сложные информационные системы, как правило, структурированы, т.е. представляют собой совокупность нескольких функциональных блоков. На этапе проектирования должна быть строго описана функциональность каждого из блоков. Здесь же обосновывается выбор методов интеграции блоков в единый информационный комплекс.
• Этап реализации. На этапе реализации происходит непосредственно написание программы на выбранном языке программирования. В техническом задании должен быть обоснован выбор именно этого языка, а также выбор СУБД и иных программных средств. 
• Этап тестирования. На этапе тестирования необходимо проверить корректность функционирования системы в нормальных условиях функционирования (когда в систему вводятся корректные исходные данные), в граничных условиях (когда на вход подаются допустимые, но редко используемые параметры или граничные параметры) и в экстремальных условиях (когда на вход системы подаются некорректные данные). Модель тестирования должна описывать результаты, которые были получены при обработке всех этих данных. 
• Этап внедрения и сопровождения. На этом этапе происходит обеспечение стабильной работы и снижение рисков возникновения сбоев в работе информационных систем; оперативное исправление технических неполадок в работе систем; предоставление новых версий, обновлений и дополнений, консультации по вопросам эксплуатации и администрирования информационных систем; консультации по установке и настройке новых версий, обновлений, дополнений и т.д.

Оценка эффективности ИС. На этом этапе собираются отзывы у клиента о процессе использования информационной системы и выявляются требования по улучшению ее работы.

Разработка ИС может вестись разными моделями, самые актуальные на сегодняшний день две модели:

1. Каскадная
2. Спиральная
3. Инкрементная

Каскадная модель.

В этой модели можно выделить следующие этапы разработки, практически не зависящие от предметной области:

- анализ требований заказчика;

- проектирование и разработка ИС;

- тестирование и опытная эксплуатация ИС;

- сдача готового программного продукта.

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

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

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

На четвертом этапе проводятся тестирование и проверка полученного программного обеспечения на предмет его соответствия требованиям технического задания. Опытная эксплуатация ПО позволяет выявить его скрытые недостатки, проявляющиеся в слабом учете специфики условий работы будущей ИС.

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

В каскадной модели обычно необходимы итерационные процедуры для уточнения требований к системе, выбора вариантов проектных решений, их изменений и дополнений при дальнейшемразвитии ИС и ее компонентов. Главный недостаток каскадной модели заключается в том, что недоработки предыдущего уровня могут обнаруживаться не сразу на последующем уровне, а позже, например, на стадии опытной эксплуатации. Так как работа над ИС может быть возвращена с любого этапа на любой предыдущий этап, то в реальности каскадная схема разработки ИС имеет более сложный вид .

Причины подобной ситуации состоят в следующем:

• Экспертами описания предметной области ИС обычно выступают будущие пользователи системы, которые, как правило, не умеют четко сформулировать свои желания и потребности по отношению к ИС; заказчики и разработчики ИС часто неадекватно понимают друг друга (исполнители обычно не являются специалистами в предметной области, решаемой задаче, а заказчики далеки от программирования);
• Отсутствие параллелизма при каскадной модели негативно отражается на исполнении проекта и загрузке специалистов (во время анализа предметной области проектировщики, специалисты по тестированию и администрированию слабо загружены работой); кроме того, сложно вносить изменения в проект по завершению этапа и передаче проекта на следующую стадию, а при нахождении разработчиками более эффективного решения его нельзя реализовать, пока не выполнено более раннее решение, поэтому доработка проекта ИС часто исключается или существенно затрудняется;
• Внесение изменений в одну из частей проекта при каскадной модели обусловливает оповещение всех разработчиков, использовавших ее ранее (в сложной ИС при множестве взаимосвязанных подсистем разработчикам важно синхронизировать внутреннюю документацию, своевременно знакомиться с изменениями, оценивая их влияние на уже полученные результаты, проводя повторное тестирование, внося изменения в готовые части проекта, отражая их во внутренней документации и рассылая исправления всем группам разработчиков);
• Изменение состава разработчиков требует помимо изучения нового материала анализа старой информации: чем сложнее проект, тем больше времени необходимо для ознакомления новичков с сутью дела;
• Обнаружение ошибок на каком-либо из этапов обусловливает возврат к предыдущим этапам выполнения проекта и вызывает дополнительные сложности в управлении проектом (лица, допустившие просчеты и ошибки, вынуждены прерывать текущую работу над новым проектом, заниматься их исправлением, срывая сроки выполнения как исправляемого, так и нового проектов).

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

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

Чем сложнее проект ИС, тем более запутаны взаимосвязи между его частями и тем дольше каждый из этапов разработки. Реальная оценка итогов возможна лишь на этапе тестирования, по завершении всех предыдущих этапов (анализа, проектирования и разработки ИС), требующих много времени и средств. Возврат на предыдущие стадии проекта ИС обусловлен не только ошибками, но и изменениями в предметной области или требованиях заказчика, а также априорной вероятностью того, что разработка проекта «зациклится» еще до сдачи проекта в эксплуатацию. При этом расходы на проект резко возрастают, а сроки сдачи готового продукта затягиваются во времени.

Пример каскадной модели (см. рис. 7)

Рисунок 7

Спиральная модель.

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

Достоинства модели:

• Позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;
• Допускает изменение требований при разработке информационной системы, что характерно для большинства разработок, в том числе и типовых;
• Обеспечивает большую гибкость в управлении проектом;
• Позволяет получить более надежную и устойчивую систему. По мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации;
• Позволяет совершенствовать процесс разработки – анализ, проводимый в каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации;
• Уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.

Недостатки модели:

• Увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;
• Затруднены операции временного и ресурсного планирования всего проекта в целом. Для решения этой проблемы необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа выполнена. План составляется на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков.