Затонский А.В. Пособие по полному жизненному циклу информационных систем

Подождите немного. Документ загружается.

101

Технология разработки малых проектов.

Малым программным средством (МПС) в целях настоящей работы будем

называть программный продукт (информационную систему), создаваемый

одним программистом или малым коллективом (2…3 человека).

Работа водиночку имеет ряд достоинств, удобств по сравнению с работой

в составе коллектива:

• Нет необходимости согласовывать сроки, разделение труда,

распределение средств.

• Нет ответственности перед коллегами.

• Свободный выбор работ и заказчиков.

• Свободный выбор технологии производства работ, возможность опускать

какие-то этапы (например, заменить составление спецификации качества

договоренностью на базе общепринятых требований; опустить создание

технологической документации по производству работ и т.п.).

Имеются и недостатки:

• Нужно быть универсалом: производить переговоры, вести договорную

работу, самостоятельно выполнять весь цикл работ от (как правило)

составления внешнего описания до сопровождения МПС.

• Нужно иметь юридическое прикрытие (ЧП, ООО) или работать на

условиях физического лица (по трудовому соглашению, договору, в

рамках личных контактов).

• Полная, единоличная ответственность перед заказчиком.

• Необходимость самостоятельно оценивать свою работу.

• Необходимость напрямую работать со всеми категориями заказчиков (от

директора до оператора).

Обычно ЖЦРП МПС имеет итеративный характер и содержит

следующие основные этапы:

1. Определение требований.

2. Анализ, составление внешнего описания (перечня требований,

функциональной спецификации и спецификации качества).

3. Проектирование (разработка архитектуры и модульной структуры).

4. Реализация и тестирование. Внутренняя и внешняя аттестация, сдача этапа

заказчику.

5. Интеграция с существующей ИС.

6. Внедрение и замена существующей ИС на разработанное МПС.

7. Определение требований новой версии. Далее цикл может повториться с п.2.

Приведем пример реализации ЖЦРП МПС, который, обычно,

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

вполне соответствующих стандартным представлениям о ЖЦРП, он содержит

ряд «внутренних» действий, направленных на формирование персонального

фонда наработок разработчика, независимо от применяемых им технологий

программирования или СУБД. Эти действия выделены курсивом. Они не

приносят дохода на стадии выполнения именно этого проекта, но накопленный

материал позволяет затем быстрее реализовать другие разработки.

102

1. Предварительное знакомство с предметной областью (до общения с

заказчиком).

2. Обследование предприятия (отдела, участка, рабочего места). Выявление

горизонтальных и вертикальных связей с другими участками.

3. Знакомство с входящей и исходящей (по отношению к ПС) документацией.

Формирование структур данных на их основе (проектирование БД).

4. Оценка стоимости разработки МПС и заключение предварительного

договора на разработку.

5. Разработка МПС на основе своих представлений о предметной области

(предварительная реализация, создание прототипа). Документирование

моделей. Документирование процесса разработки (создание и изменение

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

программы, журнал изменений хотя бы в комментариях, см. также п. 15).

Проектирование и создание (или заполнение) словарей и справочников.

6. Тестирование на первичном материале заказчика.

7. Опытная эксплуатация. Доводка МПС согласно мелким изменениям

требований.

8. Документирование МПС. Составление FAQ по вопросам пользователей

(Frequently asked questions – перечень часто задаваемых пользователями

вопросов и типичных ответов на них. Позволяет значительно экономить

время разработчика на этапах поддержки и сопровождения МПС).

9. Придание МПС «товарного вида» – написание инсталлятора, систем

защиты, счетчика запусков или журнала действий пользователя и т.п.

10. Достижение окончательных договоренностей по оплате разработки и

внедрения.

11. Постановка цели и определение стоимости сопровождения МПС.

12. Сопровождение и внесение изменений в МПС (в рамках сопровождения или

через дополнительный договор). Сохранение архивов внедренных релизов.

Поддержание товарного вида ПС: одновременное внесение изменений в

программы, документацию, help и т.п.)

13. Совмещение требований различных пользователей: настройкой, условной

компиляцией, подменой подулей.

14. Разработка новых версий МПС: новые алгоритмы (ускорение) или новые

возможности (расширение). Изменение интерфейсной части, улучшение

адаптируемости, мобильности на новые или старые платформы.

15. Выделение из готового МПС модулей многократного использования,

документирование в тексте или написание документации, составление и

документирование библиотек.

16. Разработка и предложение заказчику новых МПС, улучшающих или

расширяющих возможности внедренного МПС. Далее цикл повторяется с

шага 4.

103

Общая характеристика процесса проектирования ИС

Проект – проектно-конструкторская и технологическая документация, в

которой представлено описание проектных решений по созданию и

эксплуатации системы в конкретной программно-технической среде [65].

Проектирование системы – процесс преобразования входной информации

об объекте проектирования, о методах проектирования и об опыте

проектирования объектов аналогичного назначения в соответствии с ГОСТом в

проект ИС. Проектирование ИС сводится к последовательной формализации

проектных решений на различных стадиях жизненного цикла системы.

Осуществление проектирования системы предполагает использование

проектировщиками определенной технологии проектирования,

соответствующей масштабу и особенностям разрабатываемого проекта.

Технология проектирования системы – это совокупность методологии и

средств проектирования системы, а также методов и средств организации

проектирования (управление процессом создания и модернизации проекта

системы).

В основе технологии проектирования лежит технологический процесс,

который определяет действия, их последовательность, состав исполнителей,

средства и ресурсы, требуемые для выполнения этих действий.

Технологический процесс проектирования системы в целом делится на

совокупность последовательно-параллельных, связанных и соподчиненных

цепочек действий, каждое из которых может иметь свой предмет.

Технологии проектирования, применяемые в настоящее время,

предполагают поэтапную разработку системы. Этапы по общности могут

разделятся в стадии. Совокупность стадий и этапов, которые проходит система

в своем развитии о момента принятия решения о создании системы до момента

прекращения функционирования системы, называется жизненным циклом

системы.

Суть содержания жизненного цикла разработки системы в различных

подходах, как следует из предыдущих параграфов, одинакова и сводится к

выполнению следующих стадий:

• Планирование и анализ требований (предпроектная стадия) – системный

анализ. Исследование и анализ существующей системы, определение

требований к создаваемой системе, оформление технико-экономического

обоснования и технического задания на разработку системы.

• Проектирование (техническое проектирование, логическое

проектирование). Разработка в соответствии со сформулированными

требованиями состава автоматизируемых функций и состава

обеспечивающих подсистем, оформление технического проекта системы.

• Реализация проекта (рабочее проектирование, физическое

проектирование, программирование). Разработка и настройка программ,

наполнение баз данных, создание рабочих инструкций для персонала,

оформление рабочего проекта.

104

• Внедрение (тестирование, опытная эксплуатация). Комплексная отладка

подсистем, обучение персонала, поэтапное внедрение системы в

эксплуатацию, оформление акта о приемо-сдаточных испытаниях

системы.

• Эксплуатация системы (сопровождение, модернизация). Сбор

рекламаций и статистики о функционировании системы, исправление

ошибок и недоработок, оформление требований к модернизации системы

и ее выполнение.

Вывод

Определяющим фактором для развития средств управления

программными проектами является стремление компаний-разработчиков

повысить продуктивность своей работы, сократить сроки вывода новых

продуктов на рынок, контролировать расходы и быстро получать отдачу от

инвестиций. Достижению этих целей способствует использование сред

разработки, позволяющих снизить сложность процессов создания ИС,

увеличить их эффективность, уменьшить затраты на разработку и максимально

использовать потенциал новых технологий. Аналитики сходятся на том, что

основное направление развития инструментальных средств – их сквозная

интеграция, переход от частично интегрированных средств к интегрированным

комплексам, объединяющим возможности управления требованиями,

моделирования, разработки, тестирования, управления конфигурацией и

изменениями и развертывания приложений. В ближайшие годы такие

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

средства управления потоками работ и проектами. Рынок таких

инструментальных средств ожидает глобальная консолидация, обещающая

принести значительные выгоды разработчикам. В то же время проблема

обоснованного выбора и эффективного применения средств и методологий

создания программного обеспечения информационных систем в

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

удовлетворительных результатов от применения даже самых совершенных

технологий, если они применяются бессистемно, разработчики не обладают

необходимой квалификацией для работы с ними, и сам проект выполняется и

управляется хаотически. Систематический, обоснованный подход к выбору и

применению средств может сократить время и повысить качество разработки

ИС, обеспечить высокую степень его независимости от конкретных

разработчиков, а также снизить затраты на разработку и сопровождение.

Информационные технологии организационного управления

Одной из первых информационных технологий организационного

управления была методология планирования материальных ресурсов

предприятия MRP (Material Requirements Planning), которая использовалась

наряду с методологией объемно-календарного планирования MPS (Master

Planning Shedule). Следующим шагом было создание методологии

105

планирования производственных ресурсов (мощностей) – CRP (Capacitiy

Requirements Planning). Эта методология была принципиально похожа на MRP,

но ориентирована на расчет производственных мощностей, а не материалов и

компонентов. Эта задача требует больших вычислительных ресурсов, даже на

современном уровне. Объединение указанных выше методологий привело к

появлению задачи MRP «второго уровня» – MRP II (Manufacturing Resource

Planning) – интегрированной методологии планирования, включающей

MRP/CRP и использующей MPS и FRP (Finance Resource/requirements Planning)

– планирование финансовых ресурсов. Далее была предложена концепция ERP

(Economic Requirements Planning) – интегрированное планирование всех

«бизнес-ресурсов» предприятия. Эти методологии были поддержаны

соответствующими инструментальными средствами. В большей степени к

поддержке данных методологий применимы СУБД. Следующим шагом было

создание концепции управления производственными ресурсами – CSPP

(Customer Synchronized Resource Planning) – планирование ресурсов,

синхронизированное с потреблением. Отличием данной концепции является

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

послепродажным обслуживанием.

В связи с тем, что в современном производстве задействовано множество

поставщиков и покупателей, появилась новая концепция логистических

цепочек (Supply Chain). Суть этой концепции состоит в учете при анализе

хозяйственной деятельности всей цепочки (сети) превращения товара из сырья

в готовое изделие.

Дальнейшим развитием концепции логистических цепочек является идея

виртуального бизнеса [30], представляющего распределенную систему

нескольких компаний и охватывающего полный жизненный цикл товара, или

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

Глоссарий разновидностей информационных систем

APS (Advanced Planning and Scheduling) – усовершенствованное

(«синхронное») планирование

Методология, альтернативная концепции MRP II. Была разработана в

середине 90-х годов. Включает в себя планирование производства и снабжения,

а также диспетчеризацию производства.

В отличие от MRP II, в APS-системе согласование материалов и

мощностей происходит не последовательно, а синхронно. Благодаря этому

удается, например, «протолкнуть» в производственный график срочный заказ.

Или, скажем, рассчитать сроки его выполнения, не прерывая телефонный

разговор с клиентом. APS-системы актуальны не столько для серийных

производств, сколько для предприятий, которые борются за небольшие заказы в

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

когда на предприятии обеспечена высокая точность работы информационной

системы. Поэтому APS-подход с успехом применяется, как правило, на тех

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

106

MRP-II, а затем внедрили систему класса ERP с поддержкой функции

синхронного планирования.

ABC-анализ

АВС-анализ – метод, позволяющий классифицировать бизнес-ресурсы

фирмы по степени их важности [16]. В его основе лежит принцип Парето

(Вильфредо Парето, известный итальянский экономист XIX века, обратил

внимание на то, что большая часть богатства принадлежит меньшей части

населения и сформулировал «правило 20 x 80»: 20% всех клиентов дают 80%

прибыли, 20% всех товаров дают 80% оборота, 20% населения выпивают 80%

пива и т.п.).

По отношению к ABC -анализу правило Парето может звучать так:

надежный контроль 20% позиций позволяет на 80% контролировать систему,

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

либо его клиентура и т.п.

Например, изучив номенклатуру запасов предприятия, мы можем

выделить группу А (это, скажем, 10% запасов, стоимость которых составляет

70% всех затрат), группу B (20% запасов, составляющих 20% общих затрат) и

группу C (основной список запасов, составляющий 70% всей номенклатуры,

который занимает, однако, всего 10% всех затрат). Таким образом, очевидно,

что руководство фирмы должно наиболее жестко контролировать получение,

хранение и использование запасов группы А. По отношению к запасам группы

B контроль может быть текущим, по отношению к запасам группы С –

периодическим.

CALS (Continuous Acquisition and Life-Cycle Support)

CALS (Continuous Acquisition and Life-Cycle Support) - технология

обеспечения непрерывности поставок и жизненного цикла изделия. Концепция

CALS Была разработана в 19980-х годах Министерством обороны США.

Впоследствии нашла широкое применение в гражданской экономике. Суть

концепции - повышение эффективности жизненного цикла изделия за счет

лучшего управления информацией об этом изделии.

Стандарт CALS строится на следующих принципах:

• представление, обработка, обмен и управление данными в электронном

виде;

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

затратами;

• оптимизация и унификация способов представления, обработки и

передачи данных об изделии, процессах, среде;

• интеграция и оптимизация информационного взаимодействия всех

участников жизненного цикла изделия.

CALS-технологии особенно эффективны при создании и модернизации

высокотехнологичных наукоемких изделий, поскольку отдача от оптимизации

процесса разработки и продвижения сложных изделий особенно высока. Кроме

107

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

состоянии зачастую равны или превышают затраты на его приобретение.

В конечном итоге CALS-технологии позволяют оптимизировать:

• взаимодействие заказчика и поставщика в ходе разработки,

проектирования и производства сложной продукции;

• обслуживание, ремонт, снабжение запасными частями и модернизацию

изделия.

По статистике CALS-технологии сокращают время проектирования на

50%, затраты на изучение выполнимости проектов – на 15-40%, количество

ошибок при передаче данных – на 98%, временя поиска и извлечения данных –

на 40%, время планирования – на 70%, стоимость информации – на 15-60%,

стоимость технической документации – на 10-50%. При этом

производственные затраты сокращаются на 15-60%, а показатели качества

увеличиваются на 80%.

CRM (Customer Relationship Management)

CRM (Customer Relationship Management) – управление

взаимоотношениями с клиентами.

Концепция CRM появилась на свет в середине 1990-х годов (а первые

эффективные программные решения – к концу 1990-х). Стимулом для

разработки стала заинтересованность предприятий в инструментах,

помогающих удерживать существующих клиентов и привлекать новых.

Задача CRM-систем – отслеживать историю взаимоотношений

предприятия со своими заказчиками. Сотрудники отдела продаж, маркетинга,

обслуживания и т.п. заносят в единую базу данных информацию о каждом

контакте с клиентом (цель, объем и стоимость покупки, реакция на звонок,

письмо, факс и т.д.) и дополняют ее сведениями, полученными от самого

клиента, из средств массовой информации, интернета, бизнес-каталогов и

других источников (о семейном положении клиента, роде занятий, доходе,

изменении предпочтений, об отношении к предприятию и его продукции и

т.п.).

В итоге CRM-система позволяет формировать такой пакет предложений,

к которому клиент внутренне готов, и выходить с этим пакетом в такой момент,

когда наиболее высока вероятность сделки (покупки). Кроме того, пользователь

программы может в режиме реального времени извлекать из единой базы

данных обобщенную информацию о рыночных предпочтениях и поведении

потребителей и на этой основе строить обоснованную производственную и

маркетинговую стратегию.

Алгоритм работы CRM-системы помогает компании избавиться от

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

и противоречия в работе отделов продаж, маркетинга и обслуживания: с точки

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

принятия многих решений удается перенести с уровня руководства на уровень

простых менеджеров. Повышается лояльность клиентов, которые становятся

менее чувствительными к цене продукта. Наконец, для компании становятся

108

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

долгосрочном сотрудничестве.

CRM-системы могут поставляться отдельно либо входить в состав

комплексной корпоративной информационной системы (КИС). Их

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

сотрудника отдела продаж приходится от 25 до 3000 потенциальных

покупателей. Последовательное применение CRM-программ позволяет

увеличить продажи в среднем на 15%. При этом издержки продаж,

маркетинговых мероприятий и послепродажного обслуживания сокращаются

на 10-30%, эффективность маркетинговых компаний повышается на 5-7%, а

уровень своевременного выполнения заказов - до 90% и более. Эксперты также

напоминают, что привлечение нового покупателя обходится компании в 5-10

раз дороже, нежели удержание старого. А сокращение оттока клиентов к

конкурентам на 5% в год приводит к росту доходов компании на 25-55%.

CVP-анализ

CVP-анализ (Cast Value Profit – затраты, объем, прибыль) – метод

оптимального распределения ресурсов по видам продукции и принятия

решения о производстве товаров.

СVP-анализ также зачастую называют определением точки

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

покрытия затрат и достижения желаемой прибыли. CVP-анализ также

позволяет определить, как повлияют на прибыль изменения цены продаж,

переменных и постоянных затрат, а также доходов.

Для обеспечения выживаемости предприятия на рынке оно должно

продавать достаточно товаров, чтобы покрыть следующие виды расходов:

• Прямые расходы на производство конкретных продуктов.

• Расходы, связанные с деятельностью предприятия в целом.

Издержки также бывают двух типов – постоянные и переменные.

Переменными издержками обычно называют издержки, меняющиеся

пропорционально объему продукции и включающие, соответственно, издержки

первого вида:

• сырье и материалы на производство единицы продукции;

• электроэнергия и другие энергоресурсы на единицу товара;

• сдельная зарплата.

Постоянными обычно называют затраты, которые не меняются с

изменением объема производства и сбыта продукции. например:

• зарплата дирекции;

• зарплата административного персонала;

• затраты на социальную сферу;

• инфраструктурные издержки;

• другие виды накладных расходов.

Сумма постоянных и переменных издержек и дают цифру общих затрат

предприятия, которые оно должно покрывать за счет продажи своих товаров.

109

CVP-анализ состоит в нахождении точки на координате объема

продукции, соответствующей пересечению прямой общих издержек с прямой

дохода от продаж [62], графики которых представлены на рис. 17.

Рис. 17. Определение точки безубыточности

CVP-анализ помогает определить:

• объем продаж, необходимый для покрытия затрат (точки

безубыточности);

• объем продаж, необходимый для того, чтобы заработать желаемую

прибыль;

• влияние на прибыль изменений цены продаж, переменных затрат,

постоянных затрат и доходов;

• воздействие изменений в товарной смеси на точку безубыточности и

доход.

Преимущества CVP-анализа заключаются в следующем:

• помогает в планировании прибыли компании;

• иллюстрирует влияние операционных средств на прибыль;

• помогает в определении оптимальной пропорции постоянных и

переменных затрат компании.

Применение CVP-анализа возможно при:

• оценке производственной, сбытовой и административной деятельности;

• запуске нового бизнеса;

• введении нового товара;

• модернизации существующего бизнеса.

Ограничения CVP-анализа вызваны тем, что цена продаж остается

постоянной. Это требует следующих предположений:

• эластичность спроса является достаточно большой, чтобы оставлять

неизменной цену при увеличении объема продаж;

• цена продаж является устойчивой в течении расчетного периода;

110

• есть только один товар или постоянная товарная смесь;

• постоянная эффективность производства;

• не изменяются средства производства;

• постоянные переменные затраты на единицу продукции;

• постоянные затраты фиксируются;

• постоянные и переменные затраты хорошо разделены, определены и

оценены.

Правила CVP-анализа:

• увеличение цены продаж снижает точку безубыточности;

• увеличение переменных и постоянных затрат увеличивает точку

безубыточности.

С помощью CVP-анализа можно так же вычислить границу безопасности,

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

объем продаж без перехода бизнеса в убыточную область:

OP OB

−

= ,

где

– уровень резерва прибыльности (граница безопасности);

–

прогнозируемый объем продаж,

– объем продаж, соответствующий точке

безубыточности.

Однако у этого метода есть определенные ограничения. В частности, его

монотоварность: точка безубыточности остается точкой только для одного

товара (для двух товаров это прямая, для трех – плоскость, для четырех –

гиперплоскость). Поэтому рассчитать с помощью этого метода ценовую

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

только с помощью специального программного обеспечения.

Data mining

Data Mining (разведка данных) – это процесс обнаружения в сырых

данных ранее неизвестных, нетривиальных, практически полезных и доступных

интерпретации знаний, необходимых для принятия решений в различных

сферах человеческой деятельности.

Суть и цель технологии Data Mining можно охарактеризовать так: это

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

неочевидных, объективных и полезных на практике закономерностей [8].

Неочевидных – это значит, что найденные закономерности не

обнаруживаются стандартными методами обработки информации или

экспертным путем.

Объективных – это значит, что обнаруженные закономерности будут

полностью соответствовать действительности, в отличие от экспертного

мнения, которое всегда является субъективным.

Практически полезных – это значит, что выводы имеют конкретное

значение, которому можно найти практическое применение.