22
Рисунок 1.12 – Декомпозиция контекстной диаграммы «КАК ЕСТЬ»
Бизнес процесс «Проведение собрания» приведён на рисунке 1.13. Общее
собрание собственников, на котором жильцы дома могут получить подробный
отчёт о проделанной работе и сведения об использовании целевых взносов,
осуществляется после завершения больших работ, например, капитального
ремонта, модернизации крупномасштабных государственных услуг,
коммунальных и других работ тех же масштабов. На общем собрании жильцов
председатель правления, бухгалтеры ТСЖ, а также члены ревизионной комиссии
предоставляют подробный отчёт о проделанной работе и расходах,
обосновывают экономическую эффективность проделанной работы и
предоставляют жителям расчёты доходов и расходов. На протяжении всего
собрания ведётся протокол собрания.
23
Рисунок 1.13 – Детализация бизнес процесса «Проведение собрания»
1.2.2. Определение места проектируемой задачи в комплексе задач и её
описание
Прототипирование программного обеспечения – это деятельность по
созданию прототипов программных приложений, то есть неполных версий
разрабатываемого программного обеспечения [1]. Это действие, которое может
происходить при разработке программного обеспечения и сравнимо с
прототипированием, известным из других областей, таких как машиностроение
или производство.
Прототип обычно имитирует лишь несколько аспектов конечного
продукта и может полностью отличаться от него.
Прототипирование имеет несколько преимуществ:
Заказчик и разработчик программного обеспечения могут получить
ценную обратную связь от пользователей в начале проекта;
24
Клиент и подрядчик могут сравнивать, соответствует ли
выполненное программное обеспечение спецификации программного
обеспечения, в соответствии с которой создаётся программное обеспечение;
Это также позволяет разработчику программного обеспечения
получить представление о точности первоначальных оценок проекта и о том,
могут ли предлагаемые сроки и этапы быть успешно выполнены.
Степень полноты и методы, используемые в прототипировании,
находились на стадии разработки и обсуждения с момента его предложения, в
начале 1970-х годов.
Цель прототипа состоит в том, чтобы позволить пользователям
программного обеспечения оценивать предложения разработчиков по дизайну
конечного продукта, фактически испытывая их, вместо того, чтобы
интерпретировать и оценивать проект на основе описаний. Прототипирование
программного обеспечения обеспечивает понимание функций программного
обеспечения и потенциальных угроз или проблем. Конечные пользователи также
могут использовать прототипы для описания и обоснования требований,
которые не были рассмотрены и которые могут стать ключевыми факторами в
коммерческих отношениях между разработчиками и их клиентами. В частности,
дизайн взаимодействия интенсивно использует прототипирование с этой целью.
Этот процесс отличается от монолитного цикла разработки 1960-х и 1970-
х годов, когда сначала строится вся программа, а затем выявляются любые
несоответствия между проектированием и реализацией, что приводит к
повышению стоимости программного обеспечения и плохим оценкам времени и
затрат. Монолитный подход был назван техникой «Убийство (программного)
дракона», поскольку он предполагает, что разработчик программного
обеспечения – это единственный герой, которому нужно убить всего дракона в
одиночку. Прототипирование также позволяет избежать больших затрат и
трудностей при замене готового программного продукта.
Использование прототипов в разработке программного обеспечения имеет
много преимуществ – некоторые ощутимые, некоторые абстрактные:
Сокращение времени и затрат – прототипирование может улучшить
качество требований и спецификаций, предоставляемых разработчикам.
25
Поскольку внесение изменений обходится в геометрической прогрессии дороже,
потому что они обнаруживаются на более поздних этапах разработки, раннее
определение того, что пользователь действительно хочет, может привести к
более быстрому и менее дорогому программному обеспечению.
Улучшенное и расширенное участие пользователей –
прототипирование требует участия пользователей и позволяет им видеть
прототип и взаимодействовать с ним, что позволяет им предоставлять более
качественные и полные отзывы и спецификации. Наличие опытного образца,
рассматриваемого пользователем, предотвращает много проблем, споров и
недоразумений, которые возникают, когда каждая сторона полагает, что другая
сторона понимает, что они сказали. Поскольку пользователи знают проблемную
область лучше, чем кто-либо в команде разработчиков, более активное
взаимодействие может привести к конечному продукту, который имеет более
ощутимое и нематериальное качество. Конечный продукт, скорее всего,
удовлетворит желание пользователя выглядеть, чувствовать и работать.
Недостатки прототипирования – использование или, возможно,
неправильное использование прототипов также может иметь недостатки:
Недостаточный анализ – внимание к ограниченному прототипу
может отвлечь разработчиков от правильного анализа всего проекта. Это может
привести к упущению лучших решений, подготовке неполных спецификаций
или преобразованию ограниченных прототипов в плохо спроектированные
конечные проекты, которые сложно поддерживать. Кроме того, поскольку
прототип ограничен в функциональности, он может не масштабироваться, если
прототип используется в качестве основы для конечного результата, что может
быть не замечено, если разработчики слишком сосредоточены на создании
прототипа в качестве модели.
Смешение у пользователей прототипа и готовой системы –
пользователи могут начать думать, что прототип, предназначенный для
выбрасывания, на самом деле является конечной системой, которую просто
нужно доработать или отполировать. (Они, например, часто не знают об
усилиях, необходимых для добавления функций проверки ошибок и обеспечения
безопасности, которых у прототипа может не быть.) Это может привести к тому,
26
что прототип будет точно моделировать производительность конечной системы,
когда это не так, как в намерении разработчиков. Пользователи также могут
присоединиться к функциям, которые были включены в прототип для
рассмотрения, а затем удалены из спецификации для окончательной системы.
Если пользователи могут потребовать, чтобы все предложенные функции были
включены в окончательную систему, это может привести к конфликту.
Неправильное понимание разработчиком целей пользователя –
разработчики могут предполагать, что пользователи разделяют свои цели
(например, обеспечить основную функциональность в срок и в рамках бюджета),
не понимая более широких коммерческих вопросов. Например, представители
пользователей, участвующие в событиях программного обеспечения Enterprise
(например, PeopleSoft), возможно, видели демонстрации «аудита транзакций»
(когда изменения регистрируются и отображаются в виде сетки различий), при
этом им не говорят, что эта функция требует дополнительного кодирования и
часто требует больше аппаратного обеспечения для того, чтобы обрабатывать
дополнительные обращения к базе данных. Пользователи могут полагать, что
они могут требовать аудита в каждой области, тогда как разработчики могут
подумать, что это ползучесть функций, потому что они сделали предположения
о степени требований пользователей. Если разработчик совершил поставку до
того, как требования пользователей были рассмотрены, разработчики оказались
в затруднительном положении, особенно если управление пользователями
извлекает некоторые преимущества из-за того, что они не выполняют
требования.
Привязка разработчика к прототипу – разработчики также могут
привязаться к прототипам, на создание которых они потратили немало усилий;
это может привести к проблемам, таким как попытка преобразовать
ограниченный прототип в конечную систему, когда она не имеет
соответствующей базовой архитектуры. (Это может указывать на то, что следует
использовать одноразовые прототипы, а не эволюционные).
Чрезмерное время разработки прототипа – ключевым свойством для
прототипирования является тот факт, что это должно быть сделано быстро. Если
разработчики упустят из виду этот факт, они вполне могут попытаться
27
разработать слишком сложный прототип. Когда прототип отбрасывается, точно
разработанные требования, которые он предоставляет, могут не дать
достаточного увеличения производительности, чтобы компенсировать время,
затрачиваемое на разработку прототипа. Пользователи могут застрять в спорах о
деталях прототипа, задерживая команду разработчиков и откладывая
окончательный продукт.
Расходы на внедрение прототипов – начальные затраты на создание
команды разработчиков, ориентированной на создание прототипов, могут быть
высокими. Во многих компаниях существуют методологии разработки, и их
изменение может означать переподготовку, переоборудование или и то, и
другое. Многие компании, как правило, просто начинают создавать прототипы,
не удосужившись переучить своих работников так, как им следовало бы.
В ТСЖ "Качаловский" решено внедрить информационную систему,
интегрированную с ГИС ЖКХ. Поскольку система небольшая, её решено
создать силами приглашённого специалиста.
Разработка информационной системы включает ряд этапов.
Прототипирование – один из методов, используемых на этапе проектирования.
Он состоит в том, чтобы создать прототип информационной системы,
реализующий базовые идеи проекта.
Задача, рассмотренная в данной работе, относиться к первому этапу.
Прежде чем создавать ИС ТСЖ на прототипе ИС следует проверить
правильность выбранных решений. Именно эту задачу решает данная работа.
1.2.3. Обоснование необходимости использования вычислительной
техники для решения задачи
Государственная информационная система жилищно-коммунального
хозяйства является новшеством в сфере жилищно-коммунального хозяйства.
Вместо многочисленных разрозненных сайтов создаётся централизованный и
полный информационный ресурс-утилиты ГИС, рисунок 1.14 [17]. Это
позволяет легко оплачивать жилищно-коммунальные услуги без необходимости
28
долго ждать, голосовать в электронном виде на собраниях арендаторов,
отправлять жалобы и апелляции властям.
Рисунок 1.14 – Информационная система ГИС ЖКХ
Развитие информационных технологий и расширение их охвата
предопределяют усиление тенденции к объединению конструкторских решений,
обмену информационными системами в секторе жилищно-коммунального
хозяйства и объединению организаций по управлению (ОУ) жилищно-
коммунальным хозяйством в единое информационное пространство, как
показано на рисунке 1.15.
Кроме того, характерной особенностью реализации ГИС жилищно-
коммунальных услуг является то, что она подменяет все информационные
системы, используемые для управления жилищно-коммунальными услугами в
регионах РФ.
29
Рисунок 1.15 – Структура единого информационного пространства ЖКХ
на базе ГИС ЖКХ
30
В результате организации администрирования государственных услуг
(компании управления, ТСЖ и так далее) часто вынуждены быть независимыми
под угрозой наказания и тратить дополнительные средства, обеспечивающие
передачу данных, уже содержащихся в базах данных информационных систем в
ГИС ЖКХ.
Как видно из рисунка 1.15, для ТСЖ в рамках ГИС ЖКХ возникает
проблема поддержки работы правления ТСЖ. Это связано с тем, что данные по
организации мероприятий не должны быть доступны в ГИС ЖКХ из
соображений информационной безопасности. Таким образом, возникает
необходимость автоматизации деятельности правления ТСЖ на стороне сервера.
Это делает целесообразным применение вычислительных средств для решения
данной задачи.
1.2.4. Анализ системы обеспечения информационной безопасности и
защиты информации
Любая мера защиты является компромиссом между снижением риска и
пользовательским опытом. Сотрудник Службы безопасности всегда стремится
запретить ряд процессов из-за возникновения некоторых рисков. Однако
соглашаться с этим сразу не стоит. Специалист по безопасности должен
предложить модель процесса удовлетворительную для бизнеса, в которой эти
риски в определенной степени уменьшаются.
Политика безопасности имеет трехуровневую структуру.
Можно провести аналогию с государством: документ первого уровня – это
Конституция, а существующие в государстве доктрины, концепции, законы и
другие нормативные акты лишь дополняют и регулируют реализацию его
положений. Примерная схема показана на рисунке 1.16.
31
Рисунок 1.16 – Структура политики безопасности
Программные средства защиты информации включают:
1) Антивирусные программы – программы, предназначенные для
обнаружения компьютерных вирусов, лечения или удаления инфицированных
файлов, а также для профилактики – предотвращения заражения файлов или
операционной системы вредоносным кодом. Используется платная версия
DrWeb;
2) Используется стандартный межсетевой экран (также называемые
брандмауэрами или файрволами) Windows. Между локальной и глобальной
сетями создаются специальные промежуточные серверы, которые инспектируют
и фильтруют весь проходящий через них трафик сетевого/транспортного
уровней. Это позволяет резко снизить угрозу несанкционированного доступа
извне в корпоративные сети, но не устраняет данную опасность полностью.