(8 оценок, среднее: 4,75 из 5)
Загрузка...
Учебная работа. Дипломная работа: Разработка информационной системы Оптовая база
Одним из ведущих направлений деятель ОАО Донецкая мануфактура выпускает швейные изделия в широком ассортименте, в большей степени купальные халатики, простыни и полотенца. Не считая того, предприятие производит крашеную хлопчатобумажную пряжу для ткацкого и трикотажного производства.
Развитие автоматических информационных технологий идет наряду с возникновением новейших видов технических средств обработки и передачи инфы, совершенствованием организационных форм использования ЭВМ , насыщением инфраструктуры новенькими средствами коммуникаций. Развитие рыночных отношений привело к возникновению новейших видов предпринимательской деятель и, до этого всего, к созданию компаний, занятых информационным делом, разработкой информационных технологий, их совершенствованием, распространением компонент автоматических информационных технологий, а именно программных товаров, автоматизирующих информационные и вычислительные процессы. К их числу относят также вычислительную технику, средства коммуникаций, офисное оборудование и специальные виды услуг – информационное, техническое и консультационное сервис, обучение и т.п. Это содействовало резвому распространению и действенному использованию информационных технологий в управленческих и производственных действиях, фактически к повсеместному их применению и большенному обилию.
компании, специализирующиеся проектированием и разработкой устройств различного предназначения, в истинное время обширно употребляют разные средства как автоматического проектирования – САПР (CAD), так и мониторинга производственных действий – АСУТП (SCADA/DCS). Но для устройств своей разработки нужно разрабатывать собственные средства контроля их работоспособности и анализа свойства продукции.
Технологический процесс учета продукции на складе в магазине Cleanelly включает шаг ведение учетности продаваемой продукции.
Целью реального дипломного проекта является реализация автоматического рабочего места (АРМ) позволяющего выполнить учет продукции на складе магазина.
Для заслуги вышеуказанной цели в нужно решить последующие задачки:
¾ провести анализ бизнес-процессов магазина;
¾ изучить информационные потоки, возникающие на шаге сдачи разрабатываемого изделия;
¾ создать концептуальную и логическую модели данных;
¾ создать программное обеспечение для АРМ учета продукции
¾ провести оценку экономической эффективности информационной системы.
1 Разработка требований к программному обеспечению
1.1 анализ имеющихся решений
В истинное время существует широкий диапазон компаний, совмещающих как конкретную разработку изделий, так разработку систем управления этими изделиями. Подобные системы разрабатываются как таковыми обширно известными компаниями как 1:С предприятие и “Звезда”. В таковых системах осуществляется контроль и учет материалов, и обработка приобретенной инфы.
«1С:Предприятие» представляет собой систему прикладных решений, построенных по единым принципам и на единой технологической платформе. Управляющий может избрать решение, которое соответствует животрепещущим потребностям компании и будет в предстоящем развиваться по мере роста компании либо расширения задач автоматизации.
Система программ «1С:Предприятие» создана для решения широкого диапазона задач автоматизации учета и управления, стоящих перед оживленно развивающимися современными предприятиями. Решение животрепещущих задач учета и управления Состав программ системы «1С:Предприятие» нацелен на животрепещущие потребности компаний. Компания «1С» выпускает тиражные программные решения, созданные для автоматизации типовых задач учета и управления на предприятиях. Отличительной индивидуальностью тиражных решений компании «1С» является кропотливая проработка состава функциональности, включаемой в типовые решения. Компания»1С» анализирует опыт юзеров, применяющих программки системы «1С:Предприятие» и выслеживает изменение их потребностей.
К главным преимуществам моей системы Оптовая База можно отнести относительную низкую стоимость внедрения данной системы ,также еще ряд преимуществ:
¾ Надежность создаваемых приложений. Программный комплекс (ПК ) должен быть устойчив не только лишь к ошибкам юзеров, да и к сбоям в системе коммуникаций.
¾ Удобство использования интерфейсом;
¾ Высочайший уровень сохранности системы, что предполагает не только лишь контроль доступности тех либо других ресурсов системы и защищенность инфы на всех шагах функционирования, да и отслеживание выполняемых действий с высочайшей степенью достоверности.
1.2 анализ предметной области
Изюминка анализа предметной области заключается в том, что он дозволяет узреть всю совокупа операций организации.
Для проведения анализа и реорганизации бизнес-процессов предназначено CASE –
средство верхнего уровня All Fusion Process Modeler (BPwin), поддерживающие методологии IDEF0 (многофункциональная модель), DFD (Dataflow Diagram) и IDEF3 (Workflow Diagram). BPwin является массивным программным продуктом для сотворения моделей, позволяющих рассматривать, документировать и планировать конфигурации сложных бизнес-процессов. BPwin дает средство, для сбора всей нужной инфы о работе компании и графического изображения данной нам инфы в виде целостной и непротиворечивой модели. [24]
Исходя из убеждений функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые ведут взаимодействие меж собой, также показывается информационные, человеческие и производственные ресурсы, потребляемые каждой работой. Многофункциональная модель создана для описания имеющихся бизнес-процессов на предприятии (так именуемая модель AS-IS) и безупречного положения вещей –
того, к чему необходимо стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм, т.е. единичных описаний фрагментов системы. Поначалу проводится описание системы в целом и ее взаимодействие с миром вокруг нас (контекстная диаграмма), опосля чего же проводится многофункциональная декомпозиция –
система разбивается на подсистемы и любая система описывается раздельно (диаграммы декомпозиции). Потом любая подсистема разбивается на наиболее маленькие и так дальше для заслуги подходящей степени подробности. [26]
Если в процессе моделирования необходимо осветить специальные стороны технологии компании, BPwin дозволяет переключиться на хоть какой ветки модели на нотацию DFD либо IDEF3. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, так как они обрисовывают потоки данных, позволяя проследить, каким образом происходит обмен информацией меж бизнес-функциями снутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие меж бизнес-функциями. [26]
Исходя из убеждений последовательности выполняемых работ. И еще наиболее точную картину можно получить, дополнив модель диаграммами IDEF3. Этот способ завлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что дозволяет моделировать и рассматривать другие сценарии развития бизнес-процесса.
Для рассмотрения бизнес – действий выполняющихся на складе магазина, нужно применять лишь две методологии IDEF0 и DFD. процесс моделирования какой-нибудь системы в IDEF0 начинается с определения контекста, т.е. более абстрактного уровня описания системы либо бизнес-процессов в целом.
Модель IDEF0
. Для исследования бизнес-процессов «Формирование заказа поставщика», «Получение продукта», «Отпуск продукта», разглядим диаграммы которые представлены в виде IDEF0 диаграмме. IDEF0 система представляется как совокупа взаимодействующих работ либо функций.
В базе методологии IDEF0 лежат четыре главных понятия.
Первым из их является понятие многофункционального блока
(Activity Box)
. Многофункциональный блок графически изображается в виде прямоугольника и олицетворяет собой некую определенную функцию в рамках рассматриваемой системы
Любая из 4 сторон многофункционального блока имеет свое определенное
— верхняя сторона имеет
— левая сторона имеет
— правая сторона имеет
— нижняя сторона имеет
Вторым «китом» методологии IDEF0 является понятие интерфейсной дуги (Arrow). Графическим отображением интерфейсной дуги является однонаправленная стрелка. Любая интерфейсная дуга обязана иметь свое наименование (Arrow Label). При помощи интерфейсных дуг показывают разные объекты, в той либо другой степени определяющие процессы, происходящие в системе. При всем этом стрелки, зависимо от того в какую грань прямоугольника работы они входят либо из какой грани выходят, делятся на:
— стрелки входа (входят в левую грань многофункционального блока) – изображают изменяемые в процессе выполнения работы данные либо объекты;
— стрелки управления (входят в верхнюю грань многофункционального блока) – изображают правила и ограничения, благодаря которым производится работа;
— стрелки выхода (выходят из правой грани многофункционального блока) – изображают данные либо объекты, появляющиеся в итоге выполнения работы;
— стрелки механизма (входят в нижнюю грань многофункционального блока) – изображают ресурсы (к примеру, оборудование, человеческие ресурсы).
Третьим главным понятием эталона IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции.
Декомпозиция дозволяет равномерно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее наименее перегруженной и просто усваиваемой.
Крайним из понятий IDEF0 является глоссарий (Glossary). Для всякого из частей IDEF0: диаграмм, многофункциональных блоков, интерфейсных дуг имеющийся эталон предполагает создание и поддержание набора соответственных определений, главных слов, повествовательных изложений и т.д., которые охарактеризовывают объект, отображенный данным элементом. Этот набор именуется глоссарием и является описанием сути данного элемента. [24]
Разглядим диаграммы бизнес-процессов протекающие на складе магазина ОАО ДММ, «Cleonelly»:
Для общей видимости системы нужно выстроить контекст «Деятельность склада компании» (смотри набросок 1.1).
Набросок 1.1 – Диаграмма «Деятельность склада компании»
Опосля того как контекст установлен, проводится декомпозиция, т.е. построение последующих диаграмм в иерархии.
Любая следующая диаграмма является наиболее подробным описанием одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на рисунке 1.2. Таковым образом, вся система разбивается на подсистемы до подходящего уровня детализации, данная система разбивается на три уровня.
Набросок 1.2 – Диаграммы декомпозиции первого уровня
Дальше любой из блоков декомпозиции системы будет еще разбиваться, декомпозиция «Оформление продукта» можно узреть на рисунке 1.3, «Отпуск продукта» – набросок 1.4, «Оприходывание продукта» – набросок 1.5.
Набросок 1.3 – Диаграмма «Оформление продукта»
Набросок 1.4 – Диаграмма «Отпуск продукта»
Набросок 1.5 – Диаграмма «Оприходывание продукта»
DFD.
В базе данной методологии лежит построение модели анализируемой ИС – проектируемой либо реально имеющейся. В согласовании с методологией модель системы определяется как иерархия диаграмм потоков данных (DFD), описывающих асинхронный процесс преобразования инфы от ее ввода в систему до выдачи юзеру. Диаграммы DFD обычно строятся для приятного изображения текущей работы системы документооборота организации. Почаще всего диаграммы DFD употребляют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
Главными компонентами диаграммы потоков данных являются:
— наружные сути (графически изображены квадратом) – обозначают вещественный предмет либо физическое лицо, представляющее собой источник либо приемник инфы. К примеру: заказчики, персонал, поставщики, клиенты, склад;
— системы/подсистемы (графически смотрится как прямоугольник с округлыми углами) – работы обозначающие функции либо процессы, которые обрабатывают и изменяют информацию;
— накопители данных – представляют собой абстрактное устройство для хранения инфы, которую можно в хоть какой момент поместить в накопитель и через некое время извлечь, при этом методы помещения и извлечения могут быть хоть какими. Накопитель данных в общем случае является прототипом будущей базы данных и описание хранящихся в нем данных обязано быть увязано с информационной моделью;
— потоки данных – описывает информацию, передаваемую через некое соединение от источника к приемнику. Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая указывает направление потока.
Разглядим диаграмму потоков данных (DFD) «Отпуск продукта» набросок 1.6. На данной нам диаграмме показано движение документов при поступлении в компанию «заявки на продукт».
Набросок 1.6 – Диаграмма DFD «Отпуск продукта»
Разглядим последующую диаграмму потоков данных «Оформление продукта» (смотри набросок 1.7). тут показано процесс выполнения работ и движение документов при «отпуске продукта».
Набросок 1.7 – Диаграмма DFD «Оформление продукта»
В диаграммах потоков данных все применяемые знаки складываются в общую картину, которая дает точное инфы, принципиальные для деятель компании, реализованы ненадежно и нуждаются в реорганизации.*******
Организационная структура компании, занимающегося продажей махровых изделий, рассмотрена на примере компании ОАО “Донецкая Мануфактура М” магазина Cleonelly:
В направлении разработки систем контроля и учета материалов могут удачно решать задачи:
1. Это контроль за поставляемыми и хранящимися на складе продуктами.
2. информацию о поставщиках и пользователях
3. Также содержится информация информация и операции по товару
4. Содержится журнальчик отчета отпущенного продукта
5. Содержится справочник продуктов
6. Автоматизация складских функций (приход, расход, списание, резервирование продукта)
7. Регистрация и хранение счетов на приобретаемый и продаваемый продукт и за услуги, также выписка счетов по предоплате, с отсрочкой платежа и с доставкой продукта
8. Создание затратных и учет выданного продукта
9. Проведение инвентаризации складов с созданием сличительной ведомости, акта недостачи и избыток
10. Создание комплектов продуктов
Как обозначено главный сферой деятель этого компании является продажа хлопчатобумажных изделий. процесс проектирования включает огромное количество шагов кропотливо отрабатываемых управленческими структурами проектных компаний в течение всего времени жизни данного компании. Данный процесс не быть может единовременно изменен, потому что в нем задействовано огромное количество подразделений самого компании, наружных субподрядчиков и клиентов проектного компании. Потому компании с осторожностью относятся к внедрению информационных систем, связанных с действиями управления проектирования и разработки. Как правило, русские компании употребляют собственные выработки в данной нам области.
1.3 Сбор требований
При проектировании информационной системы (ИС) «АРМ Оптового Магазина», было нужно собрать требования, которые посодействовали бы сделать интерфейс таковым образом, что конечному юзеру (работнику магазина) было комфортно работать с разработанной ИС.
Разработка требований — это процесс, включающий мероприятия, нужные для сотворения и утверждения документа, содержащего спецификацию системных требований.
Для реализации процесса автоматизация учета и контроля материалов нужно, чтоб информационная система могла делать последующие многофункциональные требования:
¾ документирование результатов.
¾ сохранить данные в базе;
¾ высчитать количество материала на складе;
¾ Информационная система обязана быть реализована как программка на базе встроенной среды Visual Fox Pro.
Работа программки осуществляется в операционной системе Windows 2000/NT/XP.
Различают четыре главных шага процесса разработки требований (набросок 1.8):
— анализ технической осуществимости сотворения системы;
— формирование и анализ требований;
— специфицирование требований и создание соответственной документации;
— аттестация требований.
Сбор требований является принципиальным шагом проектирования ПО , так как конкретно тут все требования заказчика должны быть верно, и корректно сформулированы.
1.4 Спецификация требований
Определение корректных требований — это, наверняка, самый ответственный шаг программного проекта. Весьма принципиально, чтоб формат проекта соответствовал требованиям к ПО , собранным командой разрабов, в неприятном случае эти требования не сумеют быть поддержаны и представлены в программном продукте. Спецификация требований к ПО — Software Requirements Specification(SRS) имеет ключевое значение для всего актуального цикла разработки программного продукта. Это не только лишь производный документ, в каком определены спецификации программного проекта, да и главный документ, используемый с целью проведения аттестационных и приемочных испытаний. Аттестация — это оценка свойства работы менеджеров проекта. Она описывает степень соответствия программного продукта установленным требованиям. Спецификация SRS выступает в роли некоего механизма фиксирования системных требований, которые употребляются в качестве критериев при аттестации .
На основании SRS достигается согласие меж заказчиками и производителями программного продукта. В спецификации SRS стопроцентно описаны функции, которые должен делать разрабатываемый программный продукт. Это дозволяет возможным юзерам найти степень соответствия продукта их потребностям, также пути модификации продукта для того, чтоб он был очень полезен в решении их задач.
Понижаются временные Издержки на разработку. В подготовке спецификации SRS задействованы разные группы в организации заказчика. Они кропотливо изучат все требования еще до того, как начнется конкретная разработка проекта. Это понижает возможность следующей повторной разработки проекта, кодировки и тестирования.
При кропотливом исследовании требований, представленных в спецификации SRS, можно найти недосмотры, недоразумения и противоречия еще на ранешних шагах цикла разработки, когда задачи устранять еще легче, чем на наиболее поздних шагах.
Спецификация SRS становится основой для оценки цены и составления графика работ. Описание продукта — это настоящий базис для оценки цены проекта. В среде, где существует понятие формального предложения, SRS употребляют для утверждения оценки предложения либо цены.
При помощи верно составленных спецификаций SRS на уровне организации могут разрабатывать намного наиболее продуктивные планы аттестаций и проверок. Являясь частью контракта на разработку, SRS обеспечивает точку отсчета для оценки соответствия техническим условиям.
Благодаря спецификации SRS облегчается передача программного продукта новеньким юзерам, также его установка на остальных компах. Таковым образом, заказчикам становится проще переносить программный продукт в остальные подразделения организации, а разрабам — передавать иным заказчикам.
Спецификация SRS служит основой для модернизации. В этом документе рассматривается сам продукт, а не процесс разработки проекта, потому на ее основании можно создавать расширение завершенного продукта.
Опосля того как процесс определения и спецификации требований завершён, нужно выполнить аттестацию требований.
Спецификация требований к программному проекту обязана быть представлена в приложении А.
1.5 Аттестация требований
Аттестация обязана показать, что требования вправду определяют ту систему, которую желает иметь заказчик. Проверка требований принципиальна, потому что ошибка в спецификации требований могут привести к переделке системы и огромным затратам, если будут обнаружены во время процесса разработки системы либо опосля введения её в эксплуатацию.
Во время процесса аттестации требований должны быть выполнены разные типы проверок документации требований:
1. Проверка корректности требований.
2. Проверка на непротиворечивость.
3. Проверка на полноту.
4. Проверка на выполнимость.
Существует ряд способов аттестации требований, которые можно применять вместе либо любой в отдельности:
1. Обзор требований.
2. Прототипирование.
3. Генерация тестовых сценариев.
4. Автоматический анализ непротиворечивости.
Более приятным для заказчика системы является прототипирование.
Перед началом сотворения прототипов можно сделать диаграмму потоков пользовательского интерфейса. Таковая диаграмма употребляется для исследования взаимосвязей меж главными элементами пользовательского интерфейса.
Последующим шагом аттестации требований является конкретное создание прототипов.
Макет ПО – это частичная либо вероятная реализация предлагаемого новейшего продукта. Макеты разрешают решать три главные задачки: прояснение и окончание процесса формулировки требований, исследование других решений и создание конечного продукта.
Макет основного меню данного модуля представлен на рисунке 1.9.
1.6 Выбор методологии проектирования информационной системы
Суть структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на многофункциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачки и так дальше. процесс разбиения длится прямо до определенных процедур. Пи этом автоматизируемая система сохраняет целостное количество наименьших независящих задач, легких для осознания и решения;
— принцип иерархического упорядочивания — принцип организации составных частей задачи в иерархические древовидные структуры с добавлением новейших деталей на любом уровне.
В структурном анализе употребляются в главном две группы средств, иллюстрирующих функции, выполняемые системой и дела меж данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), более всераспространенными, посреди которых являются последующие:
— SADT (Structured Analysis and Design Technique) модели и надлежащие многофункциональные диаграммы;
— DFD (Data Flow Diagrams) диаграммы потоков данных;
— ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь».
На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО , структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупы дают полное описание ИС независимо от того, является ли она имеющейся либо вновь разрабатываемой. Состав диаграмм в любом определенном случае зависит от нужной полноты описания системы. [35]
2 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
2.1 Архитектурное проектирование
При разработке хоть какой сложной информационной системы критичным нюансом является ее архитектура, где она представляет собой концептуальное видение структуры будущих многофункциональных действий и технологий на системном уровне и во связи. Обычно сложные информационные системы организаций проектируются как композиция компонент, взаимодействующих на высочайшем уровне, которые сами могут быть системами. Архитектура информационной системы организации делает осознание системы легче, определяя ее функциональность и структуру методом, который открывает проектировочные решения и дозволяет обозревателю задавать вопросцы о ублажении проектных требований, распределении функциональности и реализации компонент.
Архитектура информационной системы организации представляет собой модель того, как информационная разработка будет поддерживать главные цели и стратегию развития автоматизируемого объекта. Она дозволяет критически мыслить и ясно выразить представление того, как встроенные наборы информационных систем должны быть структурированы для реализации этих целей. Архитектура информационной системы обрисовывает, как информационные системы, приложения и люди работают в границах всей организации в единообразной объединенной манере.
Таковым образом, архитектура информационной системы содержит в себе принятый набор компонент, которые обеспечивают «строй блоки» информационной системы. Эти «строй блоки» и их свойства определены на соответственном уровне деталировки для соответствия потребностям, производимым планировочным решениям.
При проектировании современных информационных систем организаций их архитектура обязана разрабатываться с учетом почти всех заинтересованных сторон, она обязана быть понятной юзерам, отдать возможность разрабам создать план и графики системы, позволять определять главные интерфейсы, функции и технологии, также позволять оценить график и бюджет выполнения проекта. При всем этом от архитекторов современных информационных систем требуется ответственность за создание удовлетворительной и осуществимой концепции системы на самом ранешном шаге ее разработки, поддержки цельности данной нам концепции в протяжении разработки и определения пригодности результирующей системы для использования клиентом. С иной стороны, разработка архитектуры информационной системы – это процесс описания архитектур информационных систем в достаточной деталировке, чтоб создать их наиболее полезными для разработки информационных систем.
исследование забугорного опыта указывает, что в продвинутых странах при разработке архитектуры информационной системы требуется соблюдение последующих критерий:
¾ направленность на миссии организации;
¾ направленность на требованиях;
¾ направленность на разработке;
¾ возможность к адаптации;
¾ необходимость гибкости.
Соблюдение всех этих критерий дозволяет создать архитектуру информационной системы организации наиболее совершенной и действенной.
Главными программными архитектурами, реализуемыми в истинное время являются:
¾ файл-серверная;
¾ клиент-серверная;
¾ многоуровневая.
. Эта архитектура централизованных баз данных с сетевым доступом подразумевает предназначение 1-го из компов сети в качестве выделенного сервера, на котором будут храниться файлы централизованной базы данных. В согласовании с запросами юзеров файлы с файл-сервера передаются на рабочие станции юзеров, где и осуществляется основная часть обработки данных. Центральный сервер делает в главном лишь роль хранилища файлов, не участвуя в обработке самих данных. Опосля окончания работы юзеры копируют файлы с обработанными данными назад на , откуда их могут взять и обработать остальные юзеры. Таковая организация ведения данных владеет недочетов, к примеру, при одновременном воззвании огромного количества юзеров к одним и этим же данным производительность работы резко падает, потому что нужно дождаться, пока юзер, работающий с данными, окончит работу. В неприятном случае может быть затирание исправлений, изготовленных одними юзерами, переменами, внесенными иными юзерами.
. В базе данной нам концепции лежит мысль о том, что кроме хранения файлов базы данных, центральный должен делать основную часть обработки данных. Юзеры обращаются к центральному серверу при помощи специального языка структурированных запросов (SQL, Structured Query Language), на котором описывается перечень задач, выполняемых сервером. Запросы юзеров принимаются сервером и порождают в нем процессы обработки данных. В ответ юзер получает уже обработанный набор данных. Меж клиентом и сервером передается не весь набор данных, как это происходит в технологии файл-сервер, а лишь данные, которые нужны клиенту. запрос юзера длиной всего в несколько строк способен породить процесс обработки данных, затрагивающий огромное количество таблиц и миллионы строк. В ответ клиент может получить только несколько чисел. разработка клиент-сервер дозволяет избежать передачи по сети большущих размеров инфы, переложив всю обработку данных на центральный . Не считая того, рассматриваемый подход дозволяет избежать конфликтов конфигураций одних и тех же данных обилием юзеров, которые свойственны для технологии файл-сервер. Разработка клиент-сервер реализует согласованное изменение данных обилием клиентов, обеспечивая автоматическое соблюдение целостности данных. Эти и некие остальные достоинства сделали технологию клиент-сервер весьма пользующейся популярностью. К недочетам данной нам технологии можно отнести высочайшие требования к производительности центрального сервера. Чем больше клиентов обращается к серверу, и чем больше размер обрабатываемых данных, тем наиболее массивным должен быть центральный сервер.
Исходя из этих рассуждений при проектировании архитектуры АРМ за базу была принята разработка клиент-сервер. Диаграммы размещения отражают физические связи меж программными и аппаратными компонентами системы).
2.2 Проектирование интерфейса информационной системы
Под пользовательским интерфейсом нередко соображают лишь наружный вид программки. Но на самом деле юзер принимает через него всю систему в целом, а означает, такое его осознание является очень узеньким. В реальности пользовательский интерфейс содержит в себе все нюансы дизайна, которые оказывают воздействие на взаимодействие юзера и системы. Это не только лишь экран, который лицезреет юзер. Пользовательский интерфейс состоит из огромного количества составляющих, таковых как:
набор задач юзера, которые он решает с помощью системы;
элементы управления системой;
навигация меж блоками системы;
зрительный дизайн экранов программки.
Выделим несколько более существенных преимуществ неплохого пользовательского интерфейса исходя из убеждений бизнеса:
понижение количества ошибок юзера;
понижение цены поддержки системы;
уменьшение утрат продуктивности работников при внедрении системы и наиболее резвое восстановление утраченной продуктивности;
улучшение морального состояния персонала;
уменьшение расходов на изменение пользовательского интерфейса по просьбе юзеров;
доступность функциональности системы для наибольшего количества юзеров.
АРМ оптовая база разрабатывается как приложение использующее технологию клиент-сервер.
2.2.1 Пользовательский интерфейс управляющей программки
Главным модулем «АРМ Оптовая База» является модуль Luck.exe, обеспечивающий реализацию главный функциональности диаграммы вариантов использования, представленной на рисунке 1.9 раздела 1.4.
При разработке информационной системой одной из основных задач, является создание более обычного и не загруженного интерфейса. Конкретно интерфейс программного продукта, помогает юзерам «разговаривать» с информационной системой, выступая как диалог общения юзера и системой.
интерфейс программки, администраторская часть:
1. стартовая форма программки. Данная форма запускается при запуске программного продукта образуя, таковым образом, начало диалога юзера с системой (набросок 2.3);
2. форма админа. В данной нам форме осуществляется полное управление информационной системой, т.е. добавление, удаление, изменение данных в базе данных, также по мере необходимости просмотр и печать отчетов (набросок 2.4);
3. форма «Заказчики», благодаря данной нам форме можно созидать полную информацию о заказчиках компании (набросок 2.7);
4. форма «Поставщики», благодаря данной нам форме можно созидать полную информацию о заказчиках компании (набросок 2.8).
Интерфейс программки пользовательская часть:
В окне приход продукта идет оформление продукта. При выбирании данной вкладке формы, юзер поначалу должен
В меню расход там здесь происходят операции проводимые сотрудника склада по отпуску и продаже продукта.
В меню остатки происходит подсчет продукта, наименования лежащего на складе.
В меню касса здесь хранятся информация по приходным ордерам и расходным кассовым ордерам.(снимки экрана)
2.2.2 Пользовательские интерфейсы компонент управления
Рис 2.0 основное меню программки
Основное окно программки показано на рис. 1.9. Как видно из рисунка, не считая головного меню, уже описанного чуть повыше, оно также будет содержать панель управления (клавиши «Приход», «Расход», «Доступ», «Остатки», «Касса»,«Переоценка»,«Аналитика»,«Справочники»,«Служебные» и «Выход из программки»).
Набросок 2.1 Окно меню прихода либо поступления на склад .
Набросок 2.2 Окно меню расхода
Набросок 2.2 Окно меню регулирующее права доступа к программке.
Набросок 2.3 Окно меню остатка продукта.
Набросок 2.4 Окно меню касса.
Набросок 2.4 Окно меню переоценка.
2.3 Проектирование баз данных
Для проектирования базы данных был применен ERwin 4.0 от Computer Associates Int.
ERwin — массивное и обычное в использовании средство конструирования баз данных завоевавшее обширное признание и популярность. Оно обеспечивает высочайшую продуктивность труда при разработке и сопровождении приложений с внедрением баз данных. В протяжении всего процесса — от логического моделирования требований к инфы и бизнес-правил, которые определяют базу данных, до оптимизации физической модели в согласовании с данными чертами — ERwin дозволяет наглядно показать структуру и главные элементы БД. [20]
ERwin — не только лишь наилучший инструмент для проектирования баз данных, да и средство для их резвого сотворения. ERwin улучшает модель в согласовании с физическими чертами мотивированной базы данных. В отличие от остальных инструментальных средств, ERwin автоматом поддерживает согласованность логической и физической схем и производит преобразование логических конструкций, таковых как дела многие-ко-многим, в их реализацию физически. Упрощает проектирование баз данных. Для этого довольно сделать графическую E-R модель (объект-отношение), удовлетворяющую всем требованиям к данным и ввести бизнес-правила для сотворения логической модели, которая показывает все элементы, атрибуты, дела и группировки. Erwin имеет два уровня представления модели – логический и физический. Логический уровень – это абстрактный взор на данные, на нём данные представляются, потому что смотрятся в настоящем мире, и могут называться так, как именуются в настоящем мире, к примеру «Неизменный клиент», «Отдел» либо «Фамилия сотрудника». Объекты модели, представляемые на логическом уровне, именуются сущностями и атрибутами. Логический уровень модели данных является всепригодным и никак не связан с определенной реализацией СУБД. Различают три подуровня логического уровня модели данных, отличающиеся по глубине представления инфы о данных:
— Диаграмма суть – связь (Entity Relationships Diagram (ERD));
— Модель данных, основанная на ключах (Key Based model (KB));
Полная атрибутивная модель (Fully Attributed model (FA)).
Диаграмма суть – связь включает сути и связи, отражающие главные бизнес – правила предметной области. Таковая диаграмма не очень детализирована, в неё врубаются главные сути и связи меж ними, которые удовлетворяют главным требованиям. Диаграмма суть – связь может включать связи «почти все ко почти всем» и не включать описание ключей. Как правило, ERD употребляется для презентаций и обсуждения структуры данных с профессионалами предметной области. Модель данных, основанная на ключах, — наиболее подробное области.
Логическая модель – более детализированное представление структуры данных: представляет данные в третьей обычной форме и включает все сути, атрибуты и связи (смотри приложение Б). [26]
Физическая модель данных
напротив зависит от определенной СУБД, практически являясь отображением системного каталога. В физическом уровне модели содержится информация обо всех объектах базы данных. Так как эталонов на объекты базы данных не существует (к примеру, нет эталона на типы данных), физический уровень модели зависит от определенной реализации СУБД. Как следует, одному и тому же логическому уровню модели могут соответствовать несколько различных физических уровней разных моделей. Если на логическом уровне модели не имеет большего значения, какой непосредственно тип данных у атрибута (хотя и поддерживаются абстрактные типы данных), то физически модели принципиально обрисовать всю информацию о определенных физических объектах – таблицах, колонках, индексах, процедурах и т.д. Разделение модели данных на логический и физический уровни дозволяет решить несколько принципиальных задач. [20]
Физическая модель данных представлена в приложении В.
2.4 Обоснование выбора платформы сотворения информационной системы
Visual FoxPro — зрительная среда разработки систем управления реляционными базами данных, выпускаемая в истинное время компанией Майкрософт. Крайней версией является 9.0. Употребляет язык программирования FoxPro. Версия системы 7.0 может работать в операционных системах Windows 9x и ядра NT, версии 8.0 и 9.0 — лишь в Windows XP, 2000, 2003.
FoxPro (Фокс-про?) — один из диалектов языка программирования xBase. Применяется в главном для разработки реляционных СУБД, хотя может быть использовать для разработки и остальных классов программ.Как уже отмечалось выше, язык VFP это очень дополненный и расширенный язык xBase. В Visual FoxPro язык программирования, другими словами базисной конструкцией языка является понятие класса. Начальный же вариант xBase это чистейший структурный язык, с базисным понятием процедур и функций. Таковым образом, современный язык программирования Visual FoxPro допускает кооперировать как и программирование «по старинке» описанием массы процедур, так и в стиле ООП, создавая сложную иерархию классов.
Избрал я этот язык программирования поэтому что он содержит ряд последующих преимуществ :
¾ Обширно узнаваемый формат таблиц баз данных, что дозволяет просто организовать обмен информацией с иными приложениями Microsoft Windows.
— Современная организация реляционных баз данных, позволяющая хранить информацию о таблицах базы, их свойствах, индексах и связях, задавать условия соблюдения ссылочной целостности, создавать локальные и удаленные представления (Views), связи с серверами, хранимые процедуры, исполняемые при пришествии наиболее 50 разных видов событий (VFP 7.0-9.0).
— Высочайшая скорость работы с большенными базами данных.
— Высочайшая наглядность работы с базами данных: многофункциональное окно Data session дозволяет созидать перечень открытых таблиц баз данных, их связи, фильтры, порядок по индексам, режимы буферизации, перебегать к режимам модификации структуры, к работе с информацией таблиц и пр.
— Высочайшая скорость разработки приложений с внедрением Мастеров (Wizard), Конструкторов (Designer), Построителей (Builder), режим подсказок IntelliSense при написании текста программ, системы отладки и тестирования программ.
— Возможность разработки приложений, работающих по технологии «клиент-сервер» с данными, размещенными на серверах баз данных Oracle и Microsoft SQL Server и с иными приложениями Microsoft Windows с внедрением ODBC и OLE
— Система VFP создана для использования проф программерами, потому нет смысла в русификации ее меню и языка — для хоть какого программера британский синтаксис алгоритмического языка наиболее привычен, чем российский.
2.5 Проектирование модулей
Остановимся подробней на проектировании 1-го из модулей программки и разглядим на его примере шаги нужные для сотворения проекта.
В качестве примера мной будет рассмотрено проектирование модуля, реализующего вариант использования «Оформляет заявку на поступление».
Для начала опишем потоки событий, происходящие в данном варианте использования.
Предусловием к варианту использования является поступление заявки от клиента.
5. Вариант использования начинается, когда клиент присылает заявку.
6. Менеджероткрывает форму Приход.
7. Менеджер ставит дату заявки.
8. Менеджерставит наименование продукта.
9. Менеджерзаносит количество поступаемого продукта.
10. Менеджер заносит сумму заявки.
11. Менеджерзакрывает форму.
12. Вариант использования завершается.
Постусловием к варианту использования является оформление заявки в системе и возникновение новейшего клиента в журнальчике главной формы.
Разглядим диаграмму последовательности данного варианта использования. Как видно из данной нам диаграммы Менеджер, открывая форму Приход, вызывает выполнение нескольких действий – автоматом (исходя из убеждений менеджера) заполняется дата заявки. Перечень клиентов при оформлении заявки заполняется из базы с первичной информацией. Опосля этого Менеджерзаносит все нужные данные и надавливает клавишу «Принять». При всем этом производятся последующие деяния. Все данные передаются в хранимую функцию.
3 Реализация и аттестация информационной системы
3.1 Реализация приложения
Реализация приложения по собственной сущности, является одним из трудозатратных шагов для разраба информационной системы, поэтому что, те требования, которые выдвигает заказчик, должны быть верно и корректно интегрированы в систему. Пока нет таковых программных товаров, которые могли бы «подстраиваться» под требования так именуемого заказчика и выдавать определенный набор функций для реализации системы, которые будут соответствовать сиим требованиям. Потому любой разраб должен избрать себе лучшую среду для разработки системы, но следует увидеть, что при реализации приложения никак не обойтись без написания программного кода. Конкретно при написании программного кода, будут реализовываться некоторые функции, которые обязана делать система. Зависимо от избранной среды реализации системы, программный код будет смотреться по-разному, в таковой среде как Microsoft Visual FoxPro будет один программный код, в Visual Basic иной и т.д.
В данном случае реализация приложения производилась в Microsoft Visual FoxPro.
Ниже будут описаны главные функции системы:
1. Стартовая форма системы. Данная форма является кнопочной формой и соответственно любая клавиша делает свою функцию. Клавиша регистрация админа изображена на рисунке 3.1.Данная клавиша выполнят функцию, которая открывает панель админа, если юзер имеет такие права к данной системе
2. Клавиша меню приход. Даная клавиша дозволяет провести учет поступающих продуктов на склад магазина рис 3.2.
3. В кнопочке меню расход ведется учет отпущенного продукта со склада рис 3.3.
4. В кнопочке меню доступа регулируются права использования данной программкой рис 3.4.
5. В кнопочке меню остатки хранится информация о хранящихся материалах на складе магазина рис 3.5.
6. В кнопочке меню касса храниться информация о приходных кассовых ордерах и расходных кассовых ордерах рис 3.6.
7. В кнопочке меню переоценка проходит конфигурации цены на новейшую стоимость продукта рис.3.7.
Набросок 3.1 – Стартовая форма системы
Набросок 3.2 – Форма учета поступлений материала на склад.
Набросок 3.3– Форма учета отпущенного продукта.
Набросок 3.4– Форма регулирующая права доступа к программке.
Набросок 3.5– Форма остатков продукта на складе.
Набросок 3.5–Форма о приходных кассовых ордерах и расходных кассовых ордерах.
Набросок 3.6–Форма операций по товару.
Тестирование приложения
Тестирование — процесс выполнения программки с целью обнаружения ошибок. Тестирование обеспечивает:
— обнаружение ошибок;
— демонстрацию соответствия функций программки ее предназначению;
— демонстрацию реализации требований к чертам программки;
— отображение надежности как индикатора свойства программки.
На рисунке 3.2 представлены информационные потоки процесса тестирования.
На входе процесса тестирования три потока:
— текст программки;
— начальные данные для пуска программки;
— ожидаемые результаты.
Производятся испытания, все приобретенные результаты оцениваются. Это означает, что настоящие результаты тестов сравниваются с ожидаемыми плодами. Когда находится несовпадение, фиксируется ошибка – начинается отладка.
Опосля сбора и оценивания результатов тестирования начинается отображение свойства и надежности ПО . Если часто встречаются суровые ошибки, требующие проектных конфигураций, то свойство и надежность ПО подозрительны, констатируется необходимость усиления тестирования.
Результаты, скопленные в процессе тестирования, могут оцениваться и наиболее формальным методом. Для этого употребляют модели надежности ПО , выполняющие прогноз надежности по настоящим данным о интенсивности ошибок.
Есть 2 принципа тестирования программки:
— функциональное тестирование (тестирование «темного ящика»);
— структурное тестирование (тестирование «белоснежного ящика»).
При тестировании способом «белоснежного ящика» известна внутренняя структура программки. Объектом тестирования тут является не наружное, а внутреннее друг с другом.
Тестирование «темного ящика» (функциональное тестирование) дозволяет получить композиции входных данных, обеспечивающих полную проверку всех многофункциональных требований к программке //. Программное изделие тут рассматривается как «темный ящик», чье иной класс ошибок.
Тестирование «темного ящика» обеспечивает поиск последующих категорий ошибок:
— неправильных либо отсутствующих функций;
— ошибок интерфейса;
— ошибок во наружных структурах данных либо в доступе к наружной базе данных;
— ошибок черт (нужная емкость памяти и т. д.);
— ошибок инициализации и окончания.
Подобные группы ошибок методами «белоснежного ящика» не выявляются.
В отличие от тестирования «белоснежного ящика», которое производится на ранешней стадии процесса тестирования, тестирование «темного ящика» используют на поздних стадиях тестирования. При тестировании «темного ящика» третируют управляющей структурой программки. тут внимание концентрируется на информационной области определения программной системы. При тестировании на этом шаге основное внимание уделяется пригодности решения для работы в критериях живого производства. Основное внимание уделяется исправлению ошибок и определению их значимости, также подготовки продукта к выпуску.
На шаге тестирования решают две главные задачки:
— Тестирование решения – производятся планы тестирования, сделанные на шаге планирования и расширенные и опробованные на шаге разработки;
— Пилотная эксплуатация – развертывание решения в испытательной среде и тестирование с привлечением будущих юзеров и реализацией настоящих сценариев использования системы. Эта задачка производится до начала шага развёртывания.
Цель шага тестирования – понижение риска, возникающего при вводе решения в промышленную эксплуатацию.
Для фуррора шага тестирования нужно, чтоб произошла смена дела к проекту и разраб переключился с разработки новейших функций на обеспечение подабающего свойства решения.
На данной стадии разработки информационной системы нужно провести последующие типы тестирования:
— Базисное тестирование – низкоуровневое техническое тестирование. Проводится самим разрабом в процессе написания программного кода. Применяется способ «белоснежного ящика», высочайший риск ошибок.
— Тестирование на пригодность к использованию – высокоуровневое тестирование, производится тестировщиком и будущими юзерами продукта. Применяется способ «чёрного ящика».
— Альфа- и бета-тестирование – в определениях MSF альфа-код – это в главном все начальные тексты, сделанные на шаге разработки модели действий MSF, а бета-код – код, прошедший тестирование на шаге тестирования. Потому на шаге разработки модели процесса MSF тестируется альфа-код, а на шаге тестирования – бета-код.
— Тестирование сопоставимости – от разрабатываемого решения требуется возможность интеграции и способность к взаимодействию с существующими системами и программными решениями. Данная форма тестирования нацелена на проверку интегрируемости и возможности разрабатываемого решения вести взаимодействие с существующими системами. В данном определенном случае будет проверятся правильность работы приложения на оборудовании юзера и применяемым юзером программным обеспечением.
— Тестирование производительности – нацелено на проверку того, удовлетворяет ли приложение требованиям по производительности и уровню комфортности работы по скорости.
— Тестирование документации и справочной системы – тестируются все разработанные сопровождающие документы и справочные системы.
Пилотная эксплуатация – это тестирование решения в промышленной среде. Основная задачка пилотной эксплуатации – показать, что решение способно размеренно работать критериях промышленной эксплуатации и удовлетворяет требованиям бизнеса. В процессе пилотной эксплуатации решение испытывается в настоящих критериях. Пилотная эксплуатация дает возможность юзерам высказать свое Мировоззрение о работе продукта. Руководствуясь сиим воззрением разрабом устраняются все вероятные проблемы либо создается план действий на вариант неожиданных событий. В итоге, пилотная эксплуатация дозволяет принять решение, стоит начинать полномасштабное развертывание либо отложить до устранения проблем, способных сорвать развертывание.
План процесса пилотной эксплуатации для разрабатываемой информационной системы приведен в таблице 3.2.
Таблица 3.2 – План пилотной эксплуатации
действие
Описание
1. Выбор критериев фуррора
Разраб и участники опытнейшего тестирования определяют аспекты удачливости и согласовывают их
2. Выбор юзеров и места установки
Формируется команда участников опытнейшего тестирования со стороны юзеров и разрабов. Определяется пространство развертывания пилотного процесса.
3. Подготовка юзеров и места установки
Проводится обучение юзеров – участников тесты. Подготавливается пространство установки.
4. Развёртывание опытнейшей версии
Устанавливается опытнейшая версия и врубается в работу.
5. Поддержка и мониторинг опытнейшей версии
Контроль работы юзеров и системы, оказание помощи в эксплуатации, сбор сведений о работе системы
6. Оборотная связь с юзерами и оценка результатов
Юзеры высказывают своё Мировоззрение о работе системы, указывают на недочёты и ошибки.
7. Внесение конфигураций и дополнений
Исправляются обнаруженные ошибки, вносятся конфигурации в либо процесс. Исправленные результаты предоставляются для работы и оценки юзерам.
8. Решения о развертывании
Если результаты работы опытнейшего тестирования удовлетворяют юзеров принимается решение о развертывании системы.
3.2 Методика развертывания приложения
На этом шаге разраб (либо команда) развёртывает нужные для решения технологии и составляющие, проект перебегает на стадию сопровождения и поддержки, а заказчик совсем утверждает его. Опосля развертывания команда проводит оценку проекта и опрос юзеров, чтоб узнать степень их удовлетворенности.
Цели шага развертывания:
¾ перенести решение в промышленную среду;
¾ признание заказчиком факта окончания проекта.
Развертывание компонент, соответствующих для определенного места установки, состоит из нескольких стадий: подготовки, установки, обучения и формального одобрения.
Плодами шага развертывания системы являются системы сопровождения и поддержки, хранилище документов, где располагаются все версии документов и кода, разработанных в течение проекта.
Для развертывания разрабатываемой системы был составлен план действий, который приведен в таблице 3.1.
Таблица 3.1 – План развертывания приложения
действие
Описание деяния
1. Запасное копирование
Делается запасное копирование данных юзера при его участии и согласовании методом переноса инфы на сменные носители (СD, DVD)
2. установка базисных компонент решения
Применение технологий, обеспечивающих работу решения. В этом случае – установка компонента Visual FoxPro
3. установка клиентского приложения
Перенос на комп юзера и установка окончательного варианта разработанной ИС и базы данных
4. Обучение
Делается обучение юзеров по работе с системой, разраб убеждается в корректности и осознании работы ИС клиентами
5. Передача базы познаний проекта клиенту
Заказчику передаётся вся проектная документация
6. Закрытие проекта
Составляется отчет о закрытии проекта. Заказчик подписывает акт приёмки.
Для обычного функционирования АРМ требуется операционная система Microsoft WindowsXP.
4 Управление информационным проектом
4.1 Выбор актуального цикла разработки
Одним из базисных понятий методологии проектирования ИС является понятие актуального цикла ее программного обеспечения (ЖЦ ПО ). ЖЦ ПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости его сотворения и завершается в момент его полного изъятия из эксплуатации.
Главным нормативным документом, регламентирующим ЖЦ ПО , является интернациональный эталон ISO/IEC 12207 (ISO — International Organization of Standardization – Интернациональная организация по стандартизации, IEC — International Electro technical Commission — Интернациональная комиссия по электротехнике). Он описывает структуру ЖЦ, содержащую процессы, деяния и задачки, которые должны быть выполнены во время сотворения ПО .
Эталон ISO/IEC 12207 не дает определенную модель ЖЦ и способы разработки ПО . Под моделью ЖЦ можно осознавать структуру, определяющую последовательность выполнения и связи действий, действий и задач, выполняемых в протяжении ЖЦ. Модель ЖЦ зависит от специфичности ИС и специфичности критерий, в каких создается и работает.
На нынешний денек существует много моделей актуального цикла программного обеспечения, но более популярны и всераспространены две модели это:
— спиральная модель (смотри набросок 4.1);
— итерационная модель.
Набросок 4.1 – Спиральная модель ЖЦ ПО
Для сотворения информационной системы, т.е. «Автоматическое рабочее пространство сотрудника склада оптовая база», была выбрана итерационная. Отличительным свойством итерационной модели можно именовать то, что она представляет собой формальный способ, она состоит из независящих фаз, выполняемых поочередно, и подвержена нередкому обзору (набросок 4.2). Итерационный подход отлично зарекомендовал себя при построении ИС, для которых в самом начале разработки можно довольно буквально и много сконструировать все требования, с тем, чтоб предоставить разрабам свободу воплотить их как можно лучше в техническом плане.
Достоинства итерационной модели:
модель отлично известна пользователям, не имеющим дела к разработки ПО , и конечным юзерам.
— удобность и простота внедрения, т.к. все работы производятся поэтапно (по фазам модели);
— стабильность требований;
— модель доступна для осознания;
— структурой модели может управляться даже слабо приготовленный с технической точки зрения персонал (неопытный юзер);
— модель упорядоченно совладевает со сложностями и отлично срабатывает для тех проектов, которые довольно понятны;
— модель содействует осуществлению серьезного контроля менеджмента проекта;
— упрощает работу менеджеру проекта по составлению плана и комплектации команды разрабов.
Набросок 4.2 – Итерационная модель ЖЦ ПО
Фазы модели:
— на стадии анализа определяют функции, которые обязана делать система, выделяют более приоритетные из их, требующие проработки сначала, обрисовывают информационные потребности;
— на стадии проектирования, наиболее тщательно рассматриваются процессы системы. Анализируется и, по мере необходимости, корректируется многофункциональная модель. Строятся макеты системы;
— на стадии реализации идет разработка системы;
— на стадии внедрения, готовый продукт внедряется в уже действующую систему организации. Делается обучение юзеров;
— на стадии сопровождения происходит сервис программного продукта (какое-либо добавление либо изменение, для наиболее многофункциональной работы продукта).
Выбор модели актуального цикла разработки программного обеспечения является принципиальным шагом. Потому для проекта выбор модели актуального цикла разработки программного обеспечения может осуществляться в процессе использования последующих действий.
— анализ отличительных категорий проекта, помещённых в таблицах.
— Ответить на вопросцы, приведённые для каждой группы, выделив слова «да» и «нет».
— Расположить по степени значимости группы либо вопросцы, относящиеся к каждой группы, относительно проекта, для которого выбирается применимая модель.
Команда разрабов
. Исходя из способностей, отбор персонала в состав команды разрабов проходит ещё до того момента, как будет выбрана модель актуального цикла разработки программного обеспечения. свойства таковой команды (смотри приложение Ж таблица Ж.1) играют важную роль в процессе выбора модели актуального цикла, это значит, что команда может оказать значительную помощь в выборе модели актуального цикла программного продукта, так как она несёт ответственность за удачное выполнение разработанной модели актуального цикла.
Коллектив юзеров
. На исходных стадиях проекта можно получить полное работать с разработанным программным обеспечением, и его будущей связи с командой разрабов в протяжении всего проекта. Такое знать эти конфигурации и как эти конфигурации представить в программном обеспечении.
4.2 Определение цели и области деяния программного проекта
Разрабатываемый программный продукт по учету продукта на складе, дозволит заавтоматизировать процесс поступления, структурирования и хранения данных о товаре на складе, также упростить процесс выдачи отчётов.
Целями программного проекта будут являться – создание и развертывание системы по учету продукта. Данная система создана для внутреннего использования персоналом «Cleonelly» , в большей части сотрудниками склада компании.
Для определения области деяния программного продукта, ниже будет описан, каким должен быть иле не должен быть программный проект.
Программный проект должен быть:
— для внутреннего использования в организации;
— проектом для воплощения многопользовательского доступа;
— проектом, который имеет возможность занесение, изменение и хранение сведений о товаре компании;
— проектом, который имеет возможность занесение, изменение и хранение сведений о юзерах системы;
— проектом, который имеет возможность занесение, изменение и хранение сведений о заказчиках и поставщиках организации, являющихся субъектами заключаемых сделок;
— проектом, который будет производить формирование наружной отчетности.
4.3 Создание структуры пооперационного списка работ
Для сотворения неповторимого продукта либо услуги (результата проекта) необходимо выполнить некую последовательность работ. задачка планирования проекта состоит в том, чтоб довольно буквально оценить сроки выполнения и стоимость этих работ. Чем поточнее дана оценка, тем выше свойство плана проекта. Чтоб отдать точную оценку, необходимо отлично представлять состав работ проекта, другими словами знать, какие конкретно работы необходимо выполнить для получения его результата. Лишь опосля того, как составлен перечень проектных работ, оценивается продолжительность каждой из их, и выделяются ресурсы, нужные для их выполнения. И только потом можно оценить стоимость и сроки выполнения каждой задачки и, в итоге сложения, общую стоимость и срок проекта. Вот почему определение состава работ является первым шагом при планировании проекта. Определение состава проектных работ начинается с определения шагов (либо фаз) проекта. К примеру, в проекте создание системы «Учет продукта на складе» могут быть выделены фазы:
— разработка требований к программному обеспечению;
— проектирование информационной системы;
— реализация и аттестация информационной системы;
— внедрение системы.
Опосля того как состав фаз и их результаты определены, необходимо найти последовательность этих фаз относительно друг друга и последние сроки их выполнения. Потом необходимо найти, из каких работ состоят фазы, в которой последовательности исполняются эти работы и в какие последние сроки необходимо уложиться при их выполнении.
Пооперационный список работ (набросок 4.3) был спроектирован при помощи программного продукта такового, как MS Project 2003.
Набросок 4.3 – Пооперационный список работ
4.4 Оценка продолжительности и цены разработки ПО
Оценка продолжительности.
Она определяется опосля построения пооперационного списка работ (набросок 4.3, пункт 4.3). Данную оценку продолжительности можно узреть с помощью диаграммы Ганта (приложение К).
Диаграммы являются графическим средством отображения содержащейся в проектном файле инфы. Из диаграмм можно получить зрительное один из более фаворитных методов графического представления плана проекта, используемый в почти всех программках управления проектами. [34]
В MS Project диаграмма Ганта является главным средством визуализации плана проекта. Эта диаграмма представляет собой график, на котором по горизонтали расположена шкала времени, а по вертикали размещен перечень задач. При всем этом длина отрезков, обозначающих задачки, пропорциональна продолжительности задач.
На диаграмме Ганта с отрезками может отображаться доборная информация ( с задачками показываются наименования задействованных в их ресурсов и их загрузка при выполнении задачки). [34]
Оценка издержек
Проект состоит из задач
другими словами активностей, направленных на достижение определенного результата. Чтоб задачка могла быть выполнена, на нее выделяются ресурсы
.
Принципиальное свойство ресурсов — стоимость (Cost (Издержки)) их использования в проекте. В MS Project есть два типа цены ресурсов: повременная ставка и стоимость за внедрение.
Повременная ставка (Rate) выражается в цены использования ресурса в единицу времени, к примеру 100 рублей в час либо 1000 рублей в денек. В таком случае стоимость роли ресурса в проекте составит время, в течение которого он работает в проекте, умноженное на почасовую ставку.
В данном случае использовалась повременная ставка (набросок 4.4) Общие Издержки на внедрение ресурсов можно на рисунке 4.5.
Набросок 4.4 – Повременная ставка в использовании ресурса
На данном рисунке можно узреть, что разраб системы при выполнении проекта получает 50 рублей в час; бизнес-аналитик получает 45 рублей в час, тестер 38 рублей в час. Ставка сверхурочных не учитывается.
Набросок 4.5 – Общие Издержки на использовании ресурсов проекта
4.5 Распределение ресурсов проекта
Фрагмент распределения ресурсов для системы «Учета продукта на складе» можно узреть на рисунке 4.6
Набросок 4.6 – Фрагмент распределения ресурсов проекта
Для каждой работы выполняемой в проекте сопоставляется ресурс, который будет делать данную работу. На рисунке показано полное количество трудозатрат всякого из ресурсов и конкретное количество часов затраченных в определенный денек.
4.6 Оценка экономической эффективности проекта
Расчет экономической эффективности проекта является принципиальным шагом. Конкретно тут будет рассчитываться финансовая эффективность проекта. Данный расчет покажет, на сколько выгоден проект либо проект совершенно убыточный. При расчете экономической эффективности проекта, будет нужно высчитать и срок окупаемости проекта. Срок окупаемости будет демонстрировать период, за который окупиться проект.
Входные данные.
Доборная Прибыль от реализации проекта (DP) = 38000 рублей. Добавочна Прибыль была спрогнозирована профессионалами компании.
Стартовые Инвестиции (IC) = 39396,47 рублей. Стартовые инвестиции соответствуют общим затратам на внедрение ресурсов проекта (набросок 4.5 пт 4.6)
Ставка дисконтирования (i) = 12%.
Срок, на который рассчитан проект (n) = 2 года.
Доборная прибыль от реализации проекта (DP) = 38000 рублей.
Каждогодние издержки на реализацию проекта (Z1
) = 15000 рублей.
Каждогодние издержки на реализацию проекта (Z2
) = 10000 рублей.
Годичные валютные поступления можно высчитать по формуле 4.1.
(4.1)
Годичные валютные поступления (R1
) = 23000 рублей.
Годичные валютные поступления (R2
) = 28000 рублей.
При оценке вкладывательных проектов употребляется способ расчета незапятнанного приведенного дохода, который предугадывает дисконтирование валютных потоков: все доходы и Издержки приводятся к одному моменту времени.
Центральным показателем в рассматриваемом способе является показатель NPV (net present value) – текущая стоимость валютных потоков. Это обобщенный конечный итог вкладывательной деятель в абсолютном измерении.
Принципиальным моментом является выбор ставки дисконтирования, которая обязана отражать ожидаемый усредненный уровень ссудного процента на финансовом рынке.
Незапятнанный приведенный Доход (NPV) рассчитывается по формуле 4.2
(4.2)
Rk
– годичные валютные поступления в течении n лет.
k – количество лет на сколько рассчитан проект.
IC – стартовые Инвестиции.
i – ставка дисконтирования.
По расчетам данной формулы NPV =
3460,67 руб.
Показатель NPV является абсолютным приростом, так как оценивает, на сколько приведенный доход перекрывает приведенные издержки. Потому что NPV > 0, то проект следует принять.
Коэффициент возврата инвестиций (ROI) рассчитывается по формуле 4.3
(4.3)
По расчетам (ROI) = 108,78%
Дальше нужно высчитать срок окупаемости проекта по облегченной формуле: n
ок
= Число лет до года окупаемости + (Не компенсированная стоимость на начало года окупаемости / Приток наличности в течение года окупаемости)
Таблица 4.1 Вспомогательная таблица расчёта срока окупаемости проекта
характеристики
значения
Период (лет)
0
1
2
Валютный поток
-39396,47
23000
28000
Дисконтированный валютный поток
-39396,47
20535,71
22321,43
Скопленный дисконтированный валютный поток
-39396,47
-18860,76
3460,67
= 1,84 
Срок окупаемости nok
= 1,84 года (1 год и 11 месяцев)
Потому что ROI = > 100% ( а конкретно = 108,78%) то проект считается выгодным.
Дальше нужно высчитать индекс прибыльности (PI). Индекс прибыльности указывает, сколько мы заработаем средств с всякого вложенного рубля, и рассчитывается по формуле 4.4
(4.4)
Таковым образом, индекс прибыльности равен (PI) =1,2
]]>