Файл: Рассматриваемая дипломная работа написана на базе Донецкой оао донецкая мануфактура для магазина Cleonelly.docx

Методика развертывания приложения

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

• 
   перенести решение в промышленную среду;
  
• 
   признание заказчиком факта завершения проекта.
  

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

Действие	Описание действия
1. Резервное копирование	Производится резервное копирование данных пользователя при его участии и согласовании путем переноса информации на сменные носители (СD, DVD)
2. Установка базовых компонентов решения	Применение технологий, обеспечивающих работу решения. В данном случае – установка компонента Visual FoxPro
3. Установка клиентского приложения	Перенос на компьютер пользователя и установка окончательного варианта разработанной ИС и базы данных
4. Обучение	Производится обучение пользователей по работе с системой, разработчик убеждается в правильности и понимании работы ИС клиентами
5. Передача базы знаний проекта клиенту	Заказчику передаётся вся проектная документация
6. Закрытие проекта	Составляется отчёт о закрытии проекта. Заказчик подписывает акт приёмки.

---

Для нормального функционирования АРМ требуется операционная система Microsoft WindowsXP.

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) играют важную роль в

---

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

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

2. 1   2   3   4   5   6   7   8   9   10

---

Определение цели и области действия программного проекта

Разрабатываемый программный продукт по учету товара на складе, позволит автоматизировать процесс поступления, структурирования и хранения данных о товаре на складе, а также упростить процесс выдачи отчётов. Целями программного проекта будут являться – создание и развертывание системы по учету товара. Данная система предназначена для внутреннего использования персоналом «Cleonelly» , в большей части сотрудниками склада предприятия.Для определения области действия программного продукта, ниже будет описан, каким должен быть иле не должен быть программный проект.Программный проект должен быть:

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

3. Создание структуры пооперационного перечня работ

Для создания уникального продукта или услуги (результата проекта) нужно осуществить некоторую последовательность работ. Задача планирования проекта заключается в том, чтобы достаточно точно оценить сроки исполнения и стоимость этих работ. Чем точнее дана оценка, тем выше качество плана проекта. Чтобы дать точную оценку, нужно хорошо представлять состав работ проекта, то есть знать, какие именно работы нужно выполнить для получения его результата. Только после того, как составлен список проектных работ, оценивается длительность каждой из них, и выделяются ресурсы, необходимые для их выполнения. И лишь затем можно оценить стоимость и сроки исполнения каждой задачи и, в результате сложения, общую стоимость и срок проекта. Вот почему определение состава работ является первым шагом при планировании проекта. Определение состава проектных работ начинается с определения этапов (или фаз) проекта. Например, в проекте создание системы «Учет товара на складе» могут быть выделены фазы:

---