Файл: Основы проектирования программ. Этапы создания программного обеспечения (Разработка стандартов для процесса документирования).pdf

1.3. Инкрементная стратегия разработки программных средств

Иногда можно постепенно продвигать проект вперед, по существу, не прерывая процесс разработки. Эта модель процесса является особенно полезной в более поздних стадиях проекта, когда продукт сдан, или при сопровождении разработанного продукта очень похожего на ранее существовавший. [21, с.22]

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

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

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

Рисунок 5 – Инкрементальная модель процесса разработки программных средств

Сравним модели процесса разработки.

Характеристики особенностей для рассматриваемых стратегий изображены на рисунке 6.

Рисунок 6 - Сравнение процессов разработки

Далее следуют пояснения к рисунку 6.

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

2. Шаги спиральной разработки немногочисленны, что позволяет проектировать на высоком уровне, но вместе с тем их сравнительно много, чтобы гарантировать проектировщикам понимание проблем проекта. Это преимущество аргументирует повсеместное применение спиральной стратегии.

Преимущества данной стратегии:

- не нужно заранее тратить средства, необходимые для реализации всего проекта (т.к. сперва реализуется разработка и осуществление главной функции или функции из группы высокого риска);

- по итогам реализации всякого инкремента получается функциональный продукт;

- заказчик может вмешиваться в разработку продукта на каждом этапе осуществления стратегии;

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

- есть опция поддержки непрерывного прогресса в процессе реализации продукта;

- уменьшаются затраты на первоначальную поставку программного продукта. [20, c.91]

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

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

- рыночное окно очень мало и есть необходимость оперативно ввести на рынок продукт, обладающий функциональными основными качествами;

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

- при равномерном распределении признаков разной степени важности.

ГЛАВА 2. ЭТАПЫ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1.Описание моделей бизнес-процессов объекта автоматизации

Модель «как есть» («as-is») представляет собой «снимок» положения дел в работе бухгалтера на момент обследования и позволяет понять, что делает и как функционирует данное подразделение с позиций системного анализа, а также выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации. В процессе анализа моделей бизнес-процессов «как есть» следует выяснить, соответствуют ли привлекаемые для выполнения процесса ресурсы поставленным задачам. Может оказаться, что для обеспечения выполнения процесса привлечены лишние ресурсы: материальные, финансовые, человеческие и т.д. Устранение лишних ресурсов должно привести к снижению стоимости бизнес-процесса в целом.

Для построения модели бизнес-процесса («как есть») можно будет использовано CASE-средство BPWin 4.1. с использованием методологии IDEF3.

На рисунке 7 представлена контекстная диаграмма бизнес-процесса

Рисунок 7 – Контекстная диаграмма

На рисунке 8 представлена декомпозиция контекстной диаграммы
А-1.

Рисунок 8– Диаграмма декомпозиции

2.2.Определение недостатков существующей системы обработки информации

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

Объект аренды должен быть определен предельно четко: наименование, качественные и количественные характеристики и иные данные, позволяющие однозначно идентифицировать имущество, передаваемое в аренду; для недвижимого имущества – адрес, площадь, номера и наименование помещений в соответствии с данными БТИ (экспликация и поэтажный план, которые являются приложением к договору аренды). При отсутствии этих данных согласно ч.3.ст.607 ГК договор считается незаключенным.

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

Перечисленные выше сведения целесообразно включить в раздел «Предмет договора».

Арендатор обязан своевременно вносить плату за пользование имуществом (арендную плату).

Порядок, условия и сроки внесения арендной платы определяются договором аренды. В случае, когда договором они не определены, считается, что установлены порядок, условия и сроки, обычно применяемые при аренде аналогичного имущества при сравнимых обстоятельствах.

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

1) определенных в твердой сумме платежей, вносимых периодически или единовременно;

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

3) предоставления арендатором определенных услуг;

4) передачи арендатором арендодателю обусловленной договором вещи в собственность или в аренду;

5) возложения на арендатора обусловленных договором затрат на улучшение арендованного имущества.

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

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

Традиционной на сегодняшний день является практика начисления арендной платы, при которой арендная ставка является фиксированной на весь срок договора (обычно 3-5 лет). При этом для разных арендаторов размер арендной ставки устанавливается дифференцированно и зависит от профиля арендатора (например, якорные арендаторы – супермаркет, кинотеатр и т.д. - платят меньше), арендуемой площади (чем больше площадь, тем меньше арендная ставка), этажности и т.д.

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

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

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

Размер арендной платы и размер доли от оборота определяется в процессе переговоров в каждом конкретном случае индивидуально. В настоящее время ставки, взимаемые с процента от оборота предприятия, варьируются следующим образом: 4-5% для крупных супермаркетов, 15-20% для предприятий, специализирующихся на продаже одежды и обуви, более 20% для предприятий, торгующих ювелирными изделиями и т.д.

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

2.3.Определение цели и задач проектирования ИС. Формирование требований к информационной системе

Рассмотрим все вышесказанное на примере. Целью является создание автоматизированного рабочего места бухгалтера по учета арендной платы в торговом центре «Семеновский».

Задачи и назначение программного обеспечения:

1) заключение договоров с арендаторами, возможное продление уже существующих договоров, редактирование введенных данных;

2) ведение поступлений платежей от арендаторов;

3) ведение базы платежей с определением неплательщиков;

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

5) подготовка отчетов по приему платежей, договоров, арендаторов, торговых площадей;

6) формирование отчетов и других выходных данных.

К разрабатываемой системе предъявляются следующие требования:

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

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

Система должна обладать следующими возможностями:

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