Разработка информационной системы учета призывников в администрации на примере администрации


>

FF_DONTCARE,

“Times New Roman”);

buttonPtr->SetFont(fontPtr);

Можно было бы обойтись без значительной части этого кода, если бы не строгая типизация. Чтобы задать шрифт для кнопки, необходимо обратиться к методу Set Font; однако он требует передачи в качестве аргумента указателя на объект Cfont. Приходиться объявлять и инициализировать новый объект. Инициализацию объекта Cfont выполняет его метод Create Font, который имеет жесткий интерфейс, требующий задания 14 различных аргументов. В TCL существенные характеристики шрифта (начертание Times и кегль 16 пунктов) могут быть указаны непосредственно без каких-либо объявлений или преобразовании. Более того, TCL позволяет описать и поведение кнопки непосредственно в теле создающей ее команды, тогда как в С++ или Java для этого необходим отдельный метод [3].

3.1.4. Другие языки

Существует огромное количество атрибутов, помимо степени строгости контроля типов или уровня языка, и есть очень много интересных примеров, которые не могут быть однозначно отнесены к одной из двух рассмотренных нами категории. Например, семейство Lisp занимает некоторое промежуточное положение, обладая атрибутами языков описания сценариев и языков программирования системного уровня. В Lisp впервые были реализованы такие концепции, как интерпретация и динамический контроль типов, которые широко используются в современных языках описания сценариев, А также автоматическое управление хранением и интегрированные среды разработки, применяемые в языках обеих категории [7].

3.2. Обоснование выбора языка программирования VisualBasic

Исходя из поставленной задачи и смотря на большой выбор языков и средств программирования и создания программного обеспечения мой выбор пал на язык Visual Basic и среду разработки программного обеспечения Microsoft Visual Basic 6.0 Professional Edition. Выбор этот я сделал по следующим причинам:

- данная среда разработки поддерживает все современные технологии программирования и разработки, описанные ниже (такие как методология RAD);

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

- содержит в себе помощники быстрого создания интерфейса приложения;

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

- так же в главном окне содержится окно просмотра проекта, браузер всех свойств выбранного элемента управления и окно положения формы проекта на экране монитора;

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

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

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

3.2.1. Достоинства VisualBasic

Хотя программная оболочка Visual Basic выполнена полностью графической, а сам язык программирования весьма далек от языка, применяемого для ранних версий интерпретаторов Basic , простота и элегантность Basic осталась в большой мере присущей и новым версиям. Широкие возможности Visual Basic и его простота послужили основной причиной для выбора его в качестве языка программирования для создания таких Windows-приложений как Excel. Среда программирования Visual Basic содержит все необходимые инструменты для быстрого и эффективного создания мощных программ, работающих в среде Windows.

Инструменты, имеющиеся в среде программирования Visual Basic, помогают при конструировании Basic-программ.

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

Под строкой меню имеется панель инструментов - набор кнопок, являющихся ярлыками для команд, с помощью которых осуществляется работа в среде Visual Basic. В нижней части экрана расположена панель задач. Её можно использовать для переключения между компонентами Visual Basic или для активации других приложений Windows. Также имеется окно инструментов (Toolbox), окно содержания проекта (Project Container) , окно формы(Form) , окно проекта(Project), окно непосредственного выполнения(Immediate), окно свойств(Properties) и окно макета формы(Form layout).

Файлы проектов Visual Basic имеют расширения .vbp, .wak, .vbg в имени файла. В среде Visual Basic имеется 7 инструментов.

Форма Visual Basic – это окно в интерфейсе пользователя.

Инструменты и средства управления на панели служат для того, чтобы добавлять новые элементы пользовательского интерфейса. Панель инструментов содержит также средства управления для создания объектов, выполняющих специальные “за экранные” операции: управление информацией в базе данных, контроль временных интервалов и т.д.

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

Visual Basic – программа состоит из нескольких файлов, которые собираются вместе, когда программа готова. В окне Project перечисляются все файлы, используемые при программировании.

Файлы проекта содержат список всех поддерживаемых файлов и программ проекта и их расширение vbp (Visual Basic program).

В Visual Basic 6 в окно Project можно одновременно загрузить несколько файлов проектов.

В Visual Basic предусмотрена оперативная справочная система, включающая информацию о среде программирования, инструментах и языке программирования Visual Basic.

Средства управления. С их помощью создаются объекты и формы, выводится информация в текстовом блоке, просматриваются диски и папки в системе, обрабатываются данные, вводимые пользователем, запускаются Windows-приложения и просматриваются записи баз данных. Язык программирования Visual Basic содержит несколько сотен инструкций, функций и специальных символов. Он предназначен не только для использования в программном продукте Visual Basic, Microsoft Visual Basic for Application включен в состав Microsoft Excel, Microsoft Word, Microsoft Access, Microsoft PowerPoint, Microsoft Project и других приложений для Windows. Переменные и операторы.

Visual Basic позволяет резервировать переменные с указанием размера и без оного, работать с различными типами данных, использовать константы, работать с математическими операторами и функциями, использовать дополнительные операторы. Предусмотрено использование операторов циклов For..Next, Do, объектов типа “таймер” (невидимый секундомер в программе). Точность установления времени в программе составляет 1 миллисекунду, или 1/1000 сек. Запущенный таймер постоянно работает - т.е. выполняется соответствующая процедура обработки прерывания через заданный интервал времени - до тех пор, пока пользователь не остановит таймер или не отключит программу.


3.2.2. Методология RAD

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

- небольшую команду программистов (от 2 до 10 человек);

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

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

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

Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:

- фаза анализа и планирования требований;

- фаза проектирования;

- фаза построения;

- фаза внедрения.

На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.

После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

- общая информационная модель системы;

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

- точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

- построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

- определяется необходимость распределения данных;

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

- производится физическое проектирование базы данных;

- определяются требования к аппаратным ресурсам;

- определяются способы увеличения производительности;

- завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

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

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

Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, показано в таблице 3.1.

Таблица 3.1.

< 1000 функциональных элементов

один человек

1000-4000 функциональных элементов

одна команда разработчиков

> 4000 функциональных элементов

4000 функциональных элементов на одну команду разработчиков

В качестве итога перечислим основные принципы методологии RAD:

- разработка приложений итерациями;

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

- обязательное вовлечение пользователей в процесс разработки ИС;

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

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

- необходимое использование генераторов кода;

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

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

- ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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

3.2.3. Методология функционального моделирования SADT. Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

- графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

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

- ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

- связность диаграмм (номера блоков);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- синтаксические правила для графики (блоков и дуг);

- разделение входов и управлений (правило определения роли данных).

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

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


4. Описание программного продукта «ПК инфо»

4.1. Алгоритм программного продукта

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

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

- Работа модуля «Память». При отображении на экране главного окна программы, Вы щелкаете левой клавишей мыши на кнопку «Память» во фрейме информационных модулей, после нажатия на кнопку, главное окно становится неактивным и передает работу окну свойств памяти компьютера, которое загружается и отображается на экране поверх главного окна программы. Отображение свойств физической и виртуальной памяти компьютера осуществляется при помощи специализированной API-функции – GlobalMemoryStatus, которая имеет ряд свойств. Поскольку свойства памяти могут меняться с течением достаточно небольших промежутков времени, то при помощи специального элемента управления «таймер», который повторяет обработку своей процедуры по истечении определенного промежутка времени, производится динамическое обновление API-функции – GlobalMemoryStatus и в связи с этим информация о памяти постоянно обновляется (приложение 2).

- Работа модуля «Логические диски». При щелчке левой клавиши мыши на кнопке информационного модуля «Локальные диски», главная форма передает дочерней форме свойств дисковых устройств тип устройства и становится неактивной. Далее дочерняя форма свойств дисковых устройств загружается в память, отображается на экране и обрабатывает тип устройства (в данном случае это локальные диски). При выдаче информации о дисковых устройствах задействуется очень сложный программный код, который задействует семь API-функции (FindFirstFile FindNextFile lstrlen GetLogicalDrives GetDriveType GetVolumeInformation GetDiskFreeSpace) и цикл в результате которого выдается информация о полном объеме диска (сделано это потому что не существует специальных функций для отображения полного объема диска).

Алгоритм работы информационных модулей «Съемные диски» и «CD и DVD» аналогичен работе алгоритма информационного модуля логических дисков (приложение 3).

- Работа модуля «Дисплей». При щелчке на кнопку данного информационного модуля так же загружается дочернее окно свойств видео системы и монитора компьютера. Здесь задействованы две API-функции - GetDeviceCaps и EnumDisplaySettings содержащие много параметров. При их вызове необходимые параметры заносятся в надписи на форме и список (допустимые режимы монитора). Программный код данного модуля описан в приложении 4.

- Работа модуля «Сеть». Алгоритм данного модуля является самым сложным в данном проекте, и был определен в отдельный проект. Суть его заключается в применении различных функций, как внутренних языка программирования так и API-функций для отображения полной информации о локальной сети компьютера, если таковая есть.

- Работа модуля «Процессы». Задача данного модуля отобразить все запущенные в данный момент на компьютере процессы (резидентные программы, приложения пользователя). Осуществляется это при помощи трех API-функций (CreateToolhelpSnapshot, Process32First и Process32Next), данные функции при совместной работе за один их вызов могут вернуть имя лишь одного рабочего процесса, поэтому чтобы отобразить список всех процессов их вызов помещен в цикл, условием окончания которого является возвращение функцией «Process32First» параметра со значением логического выражения «ложь», что свидетельствует об окончании перебора списка рабочих процессов.

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

- При запуске листингого модуля главное окно программы передает имя системного файла дочернему окну. Дочернее окно обрабатывает данные имени файла и открывает для просмотра в текстовом поле формы листинга необходимого файла (приложение 5).

Запуск дополнительных модулей осуществляется при помощи массива кнопок «Command8». При обработке нажатия на одну из этих кнопок программа отслеживает индекс кнопки из массива и по этому индексу определяет, какое диалоговое окно отобразить. Отображение необходимых диалоговых окон осуществляется через функцию языка программирования Visual Basic «Shell», которая запускает программу rundll32.exe в различной конфигурации и в зависимости от конфигурации на экране появляются необходимые диалоговые окна.

4.2. Руководство пользователя

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

- Информационные модули – выдают различную информацию (объем памяти, качество цвета и т. д.);

- Тестовые модули – тестирование отдельных модулей (логических и съемных дисков);

- Листинговые модули – показ листинга системного файла (boot.ini, autoexec.bat и др.);

- Дополнительные модули – стандартные модули в составе операционной системы Windows (дата и время, свойства системы и др.).

Объединены они для большего удобства и дабы не запутать пользователя, что он будет запускать.

Рамка (в дальнейшем «фрейм») «Информационные модули» содержит следующий перечень модулей о которых при нажатии на кнопку модуля будет выдана информация:

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

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

- Съемные диски – показывает аналогичную информацию, что и модуль «Логические диски», но для съемных дисков установленных на компьютере, при этом диск должен находиться в дисководе, в противном случае программа попросит его установить.

- CD и DVD – показывает аналогичную информацию, что и два предыдущих модуля, но для CD или DVD устройств, если таковые установлены на персональном компьютере пользователя.

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

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

- Процессы – отображает список работающих программ, запущенных окон и служб работающих в фоновом режиме.

Фрейм «Тестовые модули» содержит два теста, это тест логических дисков и съемных дисков. Данные тесты показывают скорость устройств при записи на них и чтении.

Фрейм с листинговыми модулями содержит пять кнопок для отображения листинга системных файлов boot.ini, system.ini, win.ini, autoexec.nt и config.nt, в данных файлах содержится системная информация загрузки и настроек операционной системы.

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

- Свойства системы;

- Установка и удаление программ;

- Язык и региональные стандарты;

- Свойства экрана;

- Свойства Интернет-браузера;

- Свойства даты и времени;

- Свойства клавиатуры;

- Свойства мыши;

- Свойства модема (если есть модем и он подключен и установлен);

- Свойства звука, речи и аудиоустройств (если на персональном компьютере установлена звуковая плата).

При запуске программы отображается главное окно (см. Рис. 4.1)

Рис. 4.1. Интерфейс главного окна программного продукта.

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

Работу информационного модуля можно описать на примере модуля - «Память»:

При отображении на экране главного окна программы, Вы щелкаете левой клавишей мыши на кнопку «Память» во фрейме информационных модулей, после нажатия на кнопку главное окно становится неактивным и загружается окно свойств памяти компьютера (Рис 4.2).

Рис. 4.2. Пример работы программного продукта (отображение модуля «Память»).

На этой форме находятся два фрейма: Frame1 и Frame2, в первом фрейме находятся текстовые поля, которые отображают информацию о физической памяти, во втором фрейме текстовые поля отображают состояние виртуальной памяти. Вся эта информация получается при помощи специальной API-функции – GlobalMemoryStatus.

Вся информация о состоянии памяти отображается динамически, постоянно обновляясь, это достигается при помощи невидимого объекта таймера

Тест дисков (будь то съемные или логические) отображает среднюю скорость записи данных на устройство и скорость чтения с него. Интерфейс окна теста локальных дисков показан на рисунке 4.3.

Рис. 4.3. Интерфейс окна тестирования дисковых устройств.

При щелчке на кнопку теста программа обрабатывает, на какую из кнопок нажали, если был вызван тест съемных дисков, то в дочернюю программу передается тип устройства «съемные диски». Далее главная форма становится неактивной и передает управление форме теста дисков, которая обрабатывает тип устройств и в зависимости от типа начинает тестирование.

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

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

Рис. 4.4. Интерфейс окна листинга системных файлов.

Дополнительные модули – это стандартные диалоговые окна операционной системы Windows, такие как «свойства системы», «установка и удаление программ» и др. Пример того как с помощью дополнительного модуля «Свойства экрана», можно открыть окно «свойства: экран» и установить изображение на рабочий стол и произвести другие настройки показан на рисунке 4.5.

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

Рис. 4.5. Пример запуска окна «Свойства: Экран».

Рис. 4.6. Работа меню программы.


Заключение

Анализируя данный программный продукт можно смело заявить, что с поставленной задачей я справился, однако это не значит, что программа полностью готова и ей уже не требуются доработки, скорее наоборот, данный программный продукт будет совершенствоваться и расширяться, в нем будут появляться все новые и новые возможности. На данном этапе программа в версии 1.0.1 практически полностью удовлетворяет поставленной задаче. Программа работает правильно и без сбоев. Как и рассчитывалось она не особо требовательна к системным ресурсам, будь то память или область жесткого диска. Однако на данном этапе есть ее некоторые недостатки, а именно данный программный продукт содержит не так много модулей для выдачи информации и особенно мало тестов. Однако я уверен что в дальнейшем этот недостаток будет исправен и будут появляться новые версии программы, которые будут содержать в себе больше информационных и тестовых модулей, будет проведена работа по усовершенствованию, нормализации и упрощению программного кода, который приведет к меньшему объему всей программы и к ее более быстрой работе. Для программы будет создан удобный установщик, который поможет легко и правильно установить программу обычным пользователем.

Источник: http://www.bestreferat.ru/referat-142051.html

Основные направления деятельности компании ООО "Кварта": стратегический анализ, описание бизнес-процессов. Анализ факторов, воздействующих на достижение стратегических целей. Реорганизация структуры как важный шаг к совершенствованию деятельности компании

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

Размещено на http://www.allbest.ru/

Курсоваяработа

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

Содержание

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

Введение

1.Стратегический анализ деятельности компании

1.1 Обоснование выбора организации

1.2 Организационно-штатная структура

1.3 Основные проблемы управления

1.4 Постановка стратегических целей

1.5 Анализ и выбор стратегии

2.анализ и оптимизация бизнес-процессов

2.1 Описание бизнес-процессов «как есть»

2.2 Проблемы и задачи

2.3 Анализ типовых вариантов процессов разработки

2.4 Оптимизация процессов разработки и сопровождения

3.Результаты и рекомендации

3.1 Описание бизнес-процессов «как должно быть»

3.2 Изменения в организационно-штатной структуре

3.3 Регламентирование деятельности

3.4 Перспективные направления автоматизации

Заключение

Список использованной литературы

Приложение

Образцы внутренних документов

Приложение

Регламент оперативного мониторинга и информационной поддержки хода исполнения контрактных обязательств

Приложение

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

Приложение

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

Приложение

Типовая должностная инструкция специалиста-стажера Управления разработки прикладных систем

Приложение

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

Введение

Данная аттестационная работа направлена на описание и оптимизацию бизнес-процессов компании-разработчика программного обеспечения (далее - ПО).

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

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

Целью данной работы является выработка стандартов работы компании и оптимизация существующих бизнес-процессов. В работе необходимо выполнить следующие задачи:

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

- описание текущего положения и штатной структуры компании;

- описание существующих бизнес-процессов;

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

- оптимизация штатной структуры компании;

- анализ проблем и выработка решений по управленческим и кадровым проблемам компании;

- создание образцов типовых документов;

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

1.Стратегический анализ деятельности компании

1.1 Обоснование выбора организации

В качестве исследуемой организации выбрана ООО «Кварта».

Основными направлениями деятельности компании являются:

- разработка программного обеспечения (ПО);

- внедрение и сопровождение программного обеспечения;

- поставка аппаратного обеспечения;

- техническая поддержка.

При этом разработка ПО ведется в двух направлениях - ПО сферы бухгалтерского учета разрабатывается на одной платформе, а ПО остальных направлений - на другой (т.н. ИИС).

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

Организационно-штатная структура компании еще больше усугубляет вышеуказанные проблемы.

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

Описание организации приведено в Таблице 1.

Таблица 1.Описание организации как объекта управления

Параметр описания

Характеристика

Название, местонахождение

ООО «Кварта», г. Москва

Назначение

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

Отраслевая принадлежность

Отрасли третичного цикла

Частная фирма

Информационные технологии

Правовая форма и вид собственности

Коммерческое предприятие, общество с ограниченной ответственностью, частное

Историческая справка

Образовалась в 1993 году. Первый заказчик Управление делами Президента РФ Начало создания финансово-бухгалтерской системы, организация ЛВС. Постепенно в компании образовался ряд направлений деятельности, которые впоследствии переросли в отдельные компании («Кварта-технологии», «Кварта-сети», «Кварта-консалтинг», Кадровое агентство «Кварта», «Сенсорные системы» и др.). Непосредственно сама компания занялась разработкой интегрированных информационных систем управления предприятием (ИИС), а также комплексной автоматизацией организаций и предприятий. Основным направлением деятельности были выбраны федеральные органы законодательной и исполнительной власти РФ. На данный момент заказчиками услуг компании являются Аппарат Правительства, Государственная Дума, Совет Федерации, Счётная палата, УД Президента РФ и большая часть Министерств, федеральных служб и агентств, включая подведомственные организации и загранучреждения, а также коммерческие организации различных форм собственности.

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

Организационная структура

См. ниже (Модель «Цепочки ценностей»)

Структура управления

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

Параметр описания

Характеристика

Ресурсы

Основной ресурс - сотрудники. Поощрение инициативных сотрудников, дружеская атмосфера в коллективе. Большое внимание уделяется обучению.

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

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

Многолетний опыт работы и большое количество завершенных проектов, что позволяет участвовать и выигрывать конкурсы.

Технические ресурсы: помещения, коммуникации (телефония, широкополосный доступ в Интернет), вычислительная техника, транспорт.

Культура

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

Ключевые факторы внешней среды

Законодательство: Изменчивое законодательство, постоянные нововведения, часто не подкреплённые методическими рекомендациями, ограниченное время на реализацию изменений.

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

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

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

Руководство

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

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

Параметр описания

Характеристика

Модель «Цепочки ценностей»

Процессы основной деятельности:

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

Интеграция: полный комплекс услуг, начиная с этапа сбора информации и проектирования, до сдачи в эксплуатации функционирующих в соответствии с требованиями заказчика программно-аппаратных комплексов

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

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

Предоставление услуг: также компания специализируется на предоставлении услуг по обслуживанию компаний, с уже работающей аппаратно-программной инфраструктурой, осуществляет, разрабатывает заказные продукты.

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

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

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

Поддержка программно-аппаратной части компании

Управление персоналом (мотивация, обучение и пр.)

Снабжение

Внутренний финансово-бухгалтерский учёт

Технологические исследования

Делопроизводство

1.2 Организационно-штатная структура

Существующая штатная структура организации приведена на Рисунке 1.

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

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

Кадровая служба не существует в виде отдельного подразделения.

Рисунок1.Существующаяштатнаяструктура.

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

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

1.3 Основные проблемы управления

В рассматриваемой организации существует ряд нижеперечисленных проблем управления.

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

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

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

Наличие 2-х направлений разработки программных продуктов, часто имеющих схожий функционал. Отсутствие общей концепции, что приводит к дублированию, а часто и несовместимости собственных разработок. Также налицо неэффективное использование ресурсов. Это влечёт за собой дополнительный штат внедренческого персонала.

Отсутствие планирования. Часто приводит к авральному выполнению проектов и нехватке сотрудников.

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

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

1.4 Постановка стратегических целей

В данный момент миссия и стратегия компании не сформулированы, поэтому попытаюсь их формулировать на основе собственного понимания и когда-то услышанных мыслей руководителя.

Миссия

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

Стратегический профиль

Текущую стратегию я бы сформулировал следующим образом:

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

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

Видение (стратегическое намерение)

1. Какой мы хотим видеть свою организацию в будущем?

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

2. Что из себя представляет наш бизнес сейчас и каким он будет в будущем?

В последнее время бизнес начал быстро развиваться. Количество заказов растет. Но четкого представления о планах и объемах работ нет практически не у кого. 80% времени персонал работает в авральном режиме. Рост внутри компании скорее носит экстенсивный характер (рост объема заказов - существенный рост штата), что не всегда оправдано. Приход новых клиентов часто происходит по принципу - мы слышали от тех-то, что есть такая компания, что у вас хорошие продукты и вас нашли. Маркетинговая политика отсутствует практически полностью.

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

3. Кто является потребителями нашей продукции (услуг) и на какую группу покупателей организация будет ориентироваться в будущем?

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

4. Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей?

Следовать последним тенденциям в области разработки. Провести реинжиниринг в соответствии с требованиями ISO9001 и пройти сертификацию. Повысить качество продукта путем улучшения качества проектирования и ввода многоуровневой системы тестирования. Уделять больше внимания вопросам информационной безопасности. Создать консолидированную систему отчётности и базу знаний. Улучшить качество управления персоналом для повышения эффективности.

Стратегические цели

1. Сроки стратегического планирования.

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

2. Генеральная цель.

В течение 2-х лет отказаться от разработки двух линеек продуктов, перевести их на единую интегрированную платформу, сделать продукт современным и качественным, требующим малых трудозатрат на сопровождение.

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

- Завершить реорганизацию структуры (создание новых структурных подразделений и распределение функций между ними)

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

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

Повысить профессиональный уровень сотрудников

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

- Внедрить систему аттестации сотрудников

- Организовать процесс повышения профессиональной подготовки кадров

- Проведение тематических семинаров

Формализовать процессы.

- Разработать должностные инструкции, ввести четкое разграничение полномочий

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

- Организовать процесс документирования производимых работ

- Стандартизировать процессы планирования и отчётности

1.5 Анализ и выбор стратегии

Результаты SWOT-анализа приведены в таблице 2 и таблице 3.

Таблица2.Анализфакторов,воздействующихнадостижениестратегическихцелей

Факторы

Шифр

Содержание

Оценка

Сильные стороны организации

S1

Сплоченный, высокопрофессиональный коллектив.

7

S2

Хорошая технологическая база, финансовая независимость

6

S3

Актуальные инновационные разработки, учитывающие специфику рынка

8

S4

Отличная репутация и долгов время пребывания на рынке

9

Итого

30

Слабые стороны организации

W1

Две линейки однородных продуктов, одна из которых использует устаревшую платформу

7

W2

Низкий уровень менеджмента организации, структура, не отвечающая текущим требованиям

8

W3

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

6

Итого

21

Возможности окружающей среды

O1

Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО

7

O2

Наличие действующих контрактов, необходимых связей, владение необходимой информацией

9

O3

Увеличение финансирования по программе «Электронная Россия», рост ИТ-рынка в целом

8

Итого

24

Угрозы окружающей среды

T1

Снижение финансирования госсектора, финансовые потрясения

4

T2

Риск активизации текущих игроков рынка

6

T3

Зависимость от тенденций рынка в области платформ разработки

8

Итого

18

Таблица 3.Итоговая стратегическая матрица

Сильные стороны организации

Слабые стороны организации

S1

S2

S3

S4

W1

W2

W3

Возможности

S3-O2 Увеличение объемов поставок решений заказчикам

S4-O3 Рост количества клиентов

S1-O3 Расширение линейки продуктов

S3-O1 Практически монополия по ряду поставляемых задач

S2-O2 Возможность работы в кредит

S4-O1 Возможность получения дополнительных разрешений

S2-O1 Возможность выпускать продукты с соотв. с самыми современными технологиями

W1-O3 Использовать средства для модернизации линейки продуктов, вкладывать в новые технологии

W3-O2 Возможность планирования работ заранее, оптимальное использование ресурсов

W1-O1 Использование партнёрской поддержки для скорейшего освоения последних технологий

W2-O3 Реорганизация системы управления, поиск профессиональных кадров

O1

O2

O3

Угрозы

S1-T1 Возможность текучки кадров. Повышать заинтересованность, постоянный мониторинг.

S2-T1 Не терять финансовую независимость, что позволит существовать в кризисные моменты достаточно продолжительное время, предоставлять возможность работы в кредит

S3-T3 Постоянно отслеживать изменение технологий, заниматься перспективными разработками.

S4-T2 Повышать авторитет, активно участвовать в конкурсах, отслеживать изменения стратегии у конкурентов

S2-T2 выпускать новый продукт раньше, чем конкуренты

W1-T3(Т1) Как можно скорее перейти на более совершенную платформу

W3-T1(Т2) Отслеживать состояние рынка, тщательно планировать деятельность

W2-T2 Привести структуру в соответствие с возникшей необходимостью, повышать квалификацию менеджеров

T1

T2

T3

T4

Граф типовых стратегий организации приведен на рисунке 2.

Выбор и обоснование стратегии

В таблице 4 приведен выбор и оценка факторов, задействованных в трёх базовых стратегиях.

Таблица4.Выбориоценкафакторов,задействованныхвтрёхбазовыхстратегиях

(лидерствопоиздержкам)

Факторы

Оценка

Реструктуризация

Дифференциация

Комбинированнаястратегия

Удельный вес фактора

Средне-взвешенная оценка фактора

Удельный вес фактора

Средне-взвешенная оценка фактора

Удельный вес фактора

Средне-взвешенная оценка фактора

S1

7

0,1

0,7

0,1

0,7

0,1

0,7

S2

6

0,15

0,9

0,2

1,2

0,18

1,08

S3

8

0,1

0,8

0,25

2

0,17

1,36

S4

9

0,15

1,35

0,25

2,25

0,2

1,8

W1

7

0,15

1,05

0,05

0,35

0,1

0,7

W2

8

0,15

1,3

0,1

0,8

0,12

0,96

W3

6

0,2

1,2

0,05

0,3

0,13

0,78

Итого

1

7,3

1

7,6

1

7,38

O1

7

0,15

1,05

0,2

1,4

0,17

1,19

O2

9

0,15

1,35

0,2

1,8

0,17

1,53

O3

8

0,15

1,2

0,25

2

0,2

1,6

T1

4

0,2

0,8

0,05

0,2

0,13

0,52

17T2

6

0,2

1,2

0,15

0,9

0,18

1,08

T3

8

0,15

1,2

0,15

1,2

0,15

1,2

Итого

1

6,8

1

7,5

1

7,12

Посуммеоценок:

По сумме оценок наилучшей стратегией является стратегия дифференциации.

Пореальностизадействованныхфакторов:

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

Выбраннаястратегия

Возможные действия в рамках реализации стратегии:

- Совершенствование и расширение линейки продуктов

- Повышение профессионального уровня сотрудников

- Повышение значимости планирования.

- Агрессивная маркетинговая политика расширение партнёрских отношений.

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

Реализациясистемыпланов.Эффективностьизменений

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

Таблица5.Определениенеобходимыхизменений

Шифр

Наименование

Вес

7S

Реакция

S1

Сплоченный, высокопрофессиональный коллектив.

0,8

Shared Values

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

S2

Хорошая технологическая база, финансовая независимость

0,7

Skills

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

S3

Актуальные инновационные разработки, учитывающие специфику рынка

1,4

Skills

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

S4

Отличная репутация и долгов время пребывания на рынке

1,7

Strategy

Skills

W1

Две линейки однородных продуктов, одна из которых использует устаревшую платформу

0,7

Strategy

Skills

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

W2

Низкий уровень менеджмента организации, структура не отвечающая текущим требований

1,2

Systems

Style

Structure

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

W3

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

1

Skills

Strategy

Разработка маркетинговой стратегии. Выработка стратегических планов и направлений развития компании на основе имеющихся знаний и возможностей.

O1

Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО

1,4

Skills

Развивать партнёрские отношения с поставщиками. Лицензировать деятельность и обеспечивать наличие разрешений во всех требуемых направлениях.

O2

Наличие действующих контрактов, необходимых связей, владение необходимой информацией

1,7

Strategy

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

O3

Увеличение финансирования по программе «Электронная Россия», рост ИТ рынка в целом

1,6

Strategy

Развивать маркетинговую политику, активно участвовать в конкурсах, предлагать качественные, функциональные, опережающие конкурентов продукты

T1

Снижение финансирования госсектора, финансовые потрясения

1,2

Strategy

Shared Values

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

T2

Риск активизации текущих игроков рынка

0,7

Strategy

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

T3

Зависимость от тенденций рынка в области платформ разработки

1

Skills

Strategy

Активно сотрудничать с поставщиками, развивать партнёрские отношения. Повышать профессиональный уровень сотрудников, заниматься инновационными разработками.

Разработкамероприятий,программипланов

Планирование

1. Создание плана реорганизации.

2. Планирование рабочего времени сотрудников.

3. Создание маркетингового плана

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

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

1. Реорганизация имеющихся департаментов и отделов, создание новых функциональных единиц, модернизация нового штатного расписания.

2. Разработка всех технических регламентов и формализация процессов.

3. Написание детальных должностных инструкций

4. Детальное распределение полномочий и распределение проектов. Назначение ответственного за результат.

Мотивация
В таблице 6 приводятся показатели качества трудовой жизни.

Таблица6.Показателикачестватрудовойжизни

в данный момент

Показатель

Положение

Справедливая заработная плата

Рыночная оплата труда

Присутствует (но ближе к нижней планке). Есть институт премирования по итогам года и завешенных проектов, но носит субъективный характер.

Обоснованная дифференциация оплаты труда

В зависимости от должности

Индивидуальная ответственность за результаты общего труда

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

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

Фактически отсутствует

Программа дополнительных выплат

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

да, по базовой ставке оплаты труда

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

да, в соответствии с КЗОТ

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

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

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

на уровне «здравого смысла»: все используемое оборудование в работе соответствует международным стандартам безопасности, офисные площади планируются из рекомендованных санитарных норм.

Гарантия занятости

Обеспечение непрерывности трудового стажа

да, в соответствии с КЗОТ

Уверенность работников в своем будущем

Да, стабильная компания, 15 лет на рыке.

Развитие способностей работников

Обучение происходит стихийно или по необходимости.

Социальная интеграция

Социально-психологический микроклимат в организации

Нейтральный. Много как позитивных, так и негативных моментов. Присутствует некая обособленность структурных единиц.

Отношение руководства и подчиненных

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

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

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

2. Управление собственностью: скорее исключает участие сотрудников в качестве партнеров по бизнесу.

Исходя из перечисленных проблем в модели 7S и описания качества трудовой жизни - отсутствует формализованная система мотивации. Введен учёт по времени прихода на работу, но отсутствует фиксация отработанного времени (сотрудники часто работают по 12 часов - но это не учитывается). Отсутствует система определения квалификации сотрудников. Определение вклада в общее дело носит субъективный характер и иногда зависит от личных симпатий. Соответственно, необходимо разработать данную систему и утвердить ее на коллективном собрании сотрудников и учредителей.

Контроль

1. Внедрить в компании стандарты ISO9001, при необходимости разработать собственные стандарты качества. Ввести многоуровневые системы тестирования и контроля качества продуктов и услуг.

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

3. Доработка внутренней ИС компании. Ведение отчетности, контроль выполнения и занятости, сравнительный анализ.

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

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

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

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

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

2.Анализ и оптимизация бизнес-процессов

2.1 Описание бизнес-процессов «как есть»

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

Разработка

Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

- постановка задачи;

- разработка;

- тестирование;

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

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

В стадии постановки задачи (например, написание ТЗ) участвуют как представители заказчика, так и сотрудники компании. При этом постановкой занимаются не профессиональные аналитики, а все, кто имеет хотя бы косвенное отношение к тематике: разработчики, внедренцы, документаторы.

Диаграмма деятельности для стадии постановки задачи приведена на Рисунке 4.

Рисунок4.Диаграммадеятельностидлястадиипостановкизадачи

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

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

Процессы непосредственно разработки, а также последующего тестирования и документирования не формализованы. Чаще всего выбираются минимально необходимые свободные ресурсы, которым и передается ТЗ. Разработкой могут заниматься не только разработчики, но и специалисты по внедрению, чья квалификация позволяет выполнять какие-либо дополнительные задания по разработке. Процедура тестирования является необязательной, модульное тестирование осуществляется по желанию и инициативе разработчика. Тестирование конечного продукта чаще всего проводится в процессе документирования, либо уже непосредственно при внедрении и обучении пользователей. Документирование также проводится по инициативе разработчика, однако, если условия контракта требуют предоставления комплекта документации, документированием может заниматься также документатор (при наличии свободных ресурсов) либо специалист по внедрению.

Контроль над процессом является эпизодическим, осуществляется в основном уже непосредственно перед сдачей проекта. Официальная оценка результатов разработки продукта отсутствует.

Внедрение и сопровождение

Процесс внедрения, а также последующего сопровождения прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 5):

- установка ПО;

- обучение пользователей;

- сбор замечаний;

- устранение замечаний;

- модернизация ПО.

Рисунок5.Видыдеятельностипривнедренииисопровождении

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

В таблице 7 приведены сводные данные по ролям и функциям.

Таблица7.Своднаятаблицаролейифункций

Функция

Роль

Итого

разработчик

специалист по внедрению

документатор

сотрудник тех. поддержки

пользователь

постановка задачи

+

+

+

+

4

разработка

+

+

2

тестирование

+

+

+

+

4

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

+

+

+

3

сбор замечаний

+

+

+

+

4

устранение замечаний

+

+

2

модернизация ПО

+

+

2

обучение

+

+

+

3

установка ПО

+

+

+

3

Всего

8

9

3

2

5

2.2 Проблемы и задачи

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

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

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

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

- определение типа процесса для сопровождения существующих проектов;

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

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

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

2.3 Анализ типовых вариантов процессов разработки

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

На рисунке 6 приведен водопадный процесс разработки с указанием результатов на каждом этапе.

Рисунок6.Водопадныйпроцессразработки

Спиральныйпроцесс

В случае спирального процесса последовательность «анализ - проектирование - реализация - тестирование» выполняется несколько раз. Основные причины использования спирального процесса обычно следующие:

- необходимость предупреждения рисков;

- необходимость предоставить заказчику частичную версию проекта до его завершения.

Основной трудностью использования спирального процесса является поддержка актуальности документации.

На рисунке 7 приведен спиральный процесс разработки.

Рисунок7.Спиральныйпроцессразработки

Инкрементальныйпроцесс

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

Унифицированныйпроцесс

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

На рисунке 8 приведен унифицированный процесс разработки.

Рисунок8.Унифицированныйпроцессразработки

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

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

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

2.4 Оптимизация процессов разработки и сопровождения

При переходе к проектному управлению необходима реорганизация бизнес-процессов в соответствии с жизненным циклом реализации проектов. Жизненный цикл проекта - это комбинация процессов и подпроцессов, необходимых для создания (реализации) объекта или решения. Так, жизненный цикл проекта в стандарте PMI (Project Management Institute, США) состоит из следующих фаз:

- начальная фаза (инициирование проекта);

- разработка;

- реализация;

- завершение.

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

Фазы могут обладать следующими характеристиками:

- границы;

- вход, выход;

- длительность;

- операции;

- участники;

- бюджеты.

Проблематика управления проектами в современном менеджменте подробно разработана и доведена до стандартов. В стандартах проектного управления PMI жизненный цикл проекта разбивается на следующие типовые этапы:

- процесс инициирования - принятие решения о начале выполнения проекта;

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

- процесс исполнения - координация людей и других ресурсов для выполнения плана;

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

- процесс управления - определение корректирующих воздействий, их согласование, утверждение и применение;

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

Процессы управления проектами приведены на рисунке 9.

Рисунок9.Процессыуправленияпроектами

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

- границы;

- документы на входе, документы на выходе;

- временной регламент;

- операции;

- участники.

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

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

- ведение систематизированного реестра проектов, позиционирование проектов по классификаторам реестра, задание типологии основных групп проектов;

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

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

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

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

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

- бюджетирование проектов, включение бюджета проектов в основной бюджет компании.

В рамках данной работы рассматриваются две группы процессов:

- проекты по разработке новых прикладных систем;

- проекты по сопровождению существующих систем.

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

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

3.Результаты и рекомендации

3.1 Описание бизнес-процессов «как должно быть

Жизненный цикл нового проекта представлен на диаграмме деятельности (Рисунок 10).

Рисунок10.Жизненныйциклновогопроекта

СозданиеУставапроекта

Устав проекта - официальный письменный документ, который формально признает и подтверждает факт существования проекта. Создание Устава проекта позволяет достичь следующих целей:


Подобные документы

  • Анализ и оптимизация бизнес-процессов

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

    контрольная работа [1,5 M], добавлен 22.02.2017

  • Моделирование и планирование бизнес-процессов

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

    лабораторная работа [605,0 K], добавлен 21.07.2015

  • Бизнес-процесс: понятие, структура, управление

    Процессный подход к управлению. Инструменты повышения эффективности бизнеса. Описание бизнес-процессов. Схема окружения бизнес-процесса. Детальное моделирование бизнес-процессов. Проведение глубокого предпроектного обследования деятельности компании.

    контрольная работа [241,5 K], добавлен 15.09.2014

  • Разработка бизнес-процессов в ЗАО "Ясень" с применением технологии управления "1С:Молокозавод"

    Понятие бизнес-моделирования. Анализ финансово-хозяйственной деятельности компании ЗАО "Ясень"; разработка бизнес-процессов производства, их оптимизация и повышение эффективности работы предприятия с внедрением программного продукта "1С:Молокозавод".

    дипломная работа [6,0 M], добавлен 15.09.2012

  • Реинжиниринг бизнес-процесса деятельности отдела контроля качества компании Destiny Development

    Проектирование совокупности взаимосвязанных бизнес-процессов предприятия как трудоемкий процесс по их моделированию. Модели прямого и обратного реинжиниринга в рамках стандарта моделирования бизнес-процессов IDEF0 на примере компании Destiny Development.

    курсовая работа [918,5 K], добавлен 22.04.2014

  • Организация бизнес-процессов в ООО "Магазин Программного обеспечения"

    Управление бизнес-процессами как часть стратегии компании. Автоматизация бизнес-процесса посредством внесения дополнительных документов в информационную систему 1С: Предприятие, используемую для учета коммерческой деятельности по распределению товаров.

    курсовая работа [26,8 K], добавлен 06.09.2015

  • Анализ компании и формирование стратегии на примере ОАО "Аэрофлот"

    Исследование политики стратегического развития компании "Аэрофлот". Характеристика организации, анализ макро-, микроокружения и внутренней среды. Карта стратегических групп, SWOT-анализ, цепочка ценностей М. Портера. Описание миссии и целей компании.

    курсовая работа [423,9 K], добавлен 18.04.2014

  • Описание и моделирование бизнес-процессов ОАО "Урал"

    Определение процессного подхода к управлению организацией. Моделирование бизнес-процессов; объекты и связи в IDEF0, преимущества и недостатки их использования. Процессно-организационная бизнес-модель компании ОАО "Урал"; паспорт процесса "Продажа".

    курсовая работа [1,4 M], добавлен 03.05.2014

  • Практическое исследование бизнес-процессов туристской компании ООО "Охота!"

    Рассмотрение сущности понятия бизнес-процессов, определение их места и роли на рынке. Описание систематизированных подходов к анализу бизнес-процессов. Разработка практических мер управления бизнесом в сфере социально-культурного сервиса и туризма.

    курсовая работа [49,8 K], добавлен 07.09.2015

  • Анализ деятельности ООО "Астор"

    Повышение конкурентоспособности компании за счет предоставления высококачественных услуг, ориентированных на клиента, - миссия компаний ООО "Астор". Цели компании, показатели их достижения. Анализ бизнес-процессов организации, характеристика работ.

    отчет по практике [868,9 K], добавлен 21.12.2013

Источник: https://knowledge.allbest.ru/management/3c0a65625b3ad78a5d43b89521206c37_0.html
grep scripting
Категория
Информатика
Тип
дипломная работа
Страницы
1 стр.
Дата
07.10.2015
Формат файла
.html — Html-документ
Архив
1082711.zip — 1.24 mb
  • razrabotka-i-vnedrenie-sajta-transportnoj-kompanii-ooo-transjenergoservis_1082711_1.rtf — 9231.06 Kb
  • Readme_docus.me.txt — 125 Bytes
Оцените работу
Хорошо  или  Плохо

  Скачать




Источник: http://docus.me/d/1082711/

Введение

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

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

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

Тенденции компьютеризации общества связаны с появлением новых профессий, связанных с вычислительной техникой, и различных категоpий пользователей ЭВМ. Если в 60-70е годы в этой сфере доминиpовали специалисты по вычислительной технике (инженеpы-электpоники и пpогpаммисты), создающие новые сpедства вычислительной техники и новые пакеты прикладных пpогpамм, то сегодня интенсивно pасшиpяется категория пользователей ЭВМ - представителей самых разных областей знаний, не являющихся специалистами по компьютеpам в узком смысле, но умеющих использовать их для решения своих специфических задач.

Пользователь ЭВМ (или конечный пользователь) должен знать общие принципы организации инфоpмационных процессов в компьютерной сpеде, уметь выбрать нужные ему информационные системы и технические сpедства и быстро освоить их применительно к своей пpедметной области. Учитывая интенсивное развитие вычислительной техники и во многом насыщенность рынка пpогpаммных продуктов, два последних качества пpиобpетают особое значение. Минимум знаний по организации компьютерных систем обычно называют компьютерной грамотностью. Не существует строго очеpченных pамок, определяющих это понятие, - каждый пользователь опpеделяет их для себя сам, но вместе с тем отсутствие такой гpамотности делает сегодня невозможным доступ ко многим узко специальным профессиям, на первый взгляд весьма далеким от компьютера.

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

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

Одним из подобных программных продуктов является SiSoftware Sandra, которая объединяет в себе выдачу информации: о системе персонального компьютера в целом, о материнской плате, процессоре, видео системе, памяти, логических дисках и др.; позволяет тестировать процессор, диски, локальную сеть; позволяет просматривать содержимое таких системных файлов в среде ОС Windows, как boot.ini, system.ini, autoexec.bat и config.sys. Однако данное программное обеспечение содержит ряд существенных недостатков, а именно: большая нагрузка на центральный процессор при работе программы, большой объем памяти, занимаемый программой при ее работе, большой объем дискового пространства, занимаемый данным программным продуктом, при его установке (около 5 мегабайт), к тому же данный программный продукт является ShareWare, т. е. его необходимо приобретать за некоторое количество денег, чтобы его можно было использовать.

Как уже говорилось ранее, на данный момент на рынке программного обеспечения один единственный программный продукт подобного рода, который объединяет в себе выдачу информации и тестирование отдельных модулей персонального компьютера, этот программный продукт - SiSoftware Sandra. Поэтому создание подобного программного продукта весьма актуально на сегодняшний момент, дабы дать возможность пользователям персонального компьютера, которые хотят приобрести такое программное обеспечение, выбирать между несколькими программами, а не брать именно SiSoftware Sandra, только потому что этот программный продукт является единственным в своем роде. К тому же лично для меня, как разработчика программного обеспечения было весьма интересно создать программный продукт «ПК Инфо», который я назвал PCInfo, дабы проверить свои возможности, знания и навыки программирования и разработки программного обеспечения в целом, а так же узнать много нового. Мой программный продукт является аналогом, и прямым конкурентом уже упомянутого программного продукта SiSoftware Sandra. По сравнению с аналогами, мой программный продукт обладает рядом преимуществ, которых нет у его аналогами, а именно: малый объем жесткого диска, занимаемый программой (около трехсот килобайт), меньший объем оперативной памяти, занимаемый программой при ее запуске и работе, меньшая загруженность центрального процессора при работе программы, более быстрая работа программного продукта по сравнению с основными аналогами, к тому же, мой программный продукт в версии 1.0.1 является Freeware, т. е. бесплатным программным обеспечением, что весьма существенно для подобного рода программного обеспечения.

Дипломная работа содержит 66 страниц, из них приложения содержат 12 страниц, 8 рисунков, библиографический список из 11-ти наименований.


1. Анализ информационных технологий

1.1. История развития информационных технологий

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

На смену «ручной» информационной технологии в конце 19 века пришла «механическая». Изобретение пишущей машинки, телефона, диктофона, модернизация системы общественной почты - все это послужило базой для принципиальных изменений в технологии обработки информации и, как следствие, в продуктивности работы. По существу «механическая» технология проложила дорогу к формированию организационной структуры существующих учреждений [10].

40 - 60-е гг. 20 века характеризуются появлением «электрической» технологии, основанной на использовании электрических пишущих машинок со съемными элементами, копировальных машин на обычной бумаге, портативных диктофонов. Они улучшили учрежденческую деятельность за счет повышения качества, количества и скорости обработки документов.

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

Сложившиеся в 60-х годах концепции применения автоматизированных систем управления (АСУ) не всегда и не в полной мере отвечают задаче совершенствования управления и оптимальной реализации компонентов информационной технологии, методологически эти концепции нередко опираются на представления о неограниченных возможностях «кнопочной»информационной технологии при непрерывном наращивании вычислительной мощности систем АСУ в применении наиболее общих имитационных моделей, которые в ряде случаев далеки от реального механизма оперативного управления.

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

Начиная с 70-х годов сформировалась тенденция перенесения центра тяжести развития АСУ на фундаментальные компоненты информационных технологий (особенно на аналитическую работу) с максимальным применением человеко-машинных процедур. Однако по-прежнему вся эта работа проводилась на мощных ЭВМ, размещенных централизованно в вычислительных центрах. При этом в основу построения подобных АСУ положена гипотеза, согласно которой задачи анализа и принятия решений относились к классу формализуемых, поддающихся математическому моделированию. Предполагалось, что такие АСУ должны повысить качество, полноту, подлинность и своевременность информационного обеспечения лиц, принимающих решения, эффективность работы которых будет возрастать благодаря увеличению числа анализируемых задач.

Однако внедрение подобных систем дало весьма отрезвляющие результаты. Оказалось, что применяемые экономико-математические модели имеют ограниченные возможности практического использования: аналитическая работа и процесс принятия решений происходят в отрыве от реальной ситуации и не подкрепляются информационным процессом формирования. Для каждой новой задачи требуется новая модель, а поскольку модель создавалась специалистами по экономико-математическим методам, а не пользователем, то процесс принятия решений происходит как бы не в реальном времени и теряется творческий вклад самого пользователя, особенно при решении нетиповых управленческих задач. При этом вычислительный потенциал управления, сосредоточенный в вычислительных центрах, находится в отрыве от других средств и технологий обработки информации вследствие не эффективной работы нижних ступеней и необходимости непрерывных конверсий информации. Это так же понижает эффективность информационной технологии при решении задач на верхних ступенях управленческой лестницы. К тому же для сложившейся в АСУ организационной структуры технических средств характерны низкий коэффициент их использования, значительные сроки (не всегда выполняемые) проектирования автоматизированных систем и не высокая их рентабельность из-за слабого воздействия результатов автоматизации на эффективность управления.

С появлением персональных компьютеров на «гребне микропроцессорной революции» происходит принципиальная модернизация идеи АСУ: от вычислительных центров и централизации управления, к распределенному вычислительному потенциалу, повышению однородности технологии обработки информации и децентрализации управления. Такой подход нашел свое воплощение в системах поддержки принятия решений (СППР) и экспертных системах (ЭС), которые характеризуют новый этап компьютеризации технологии организационного управления по существу - этап персонализации АСУ. Системность - основной признак СППР и признание того, что самая мощная ЭВМ не может заменить человека. В данном случае речь идет о структурной человеко-машинной единице управления, которая оптимизируется в процессах работы: возможности ЭВМ расширяются за счет структуризации пользователем решаемых задач и пополнения ее базы знаний, а возможности пользователя - за счет автоматизации тех задач, которые ранее было нецелесообразно переносить на ЭВМ по экономическим или техническим соображениям. Становится возможным анализировать последствия различных решений и получать ответы на вопросы типа: «что будет, если...?», не тратя времени на трудоемкий процесс программирования.

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

Концепция СППР требует пересмотра существующих подходов к управлению трудовыми процессами в учреждении. По существу на базе СППР формируется новая человеко-машинная трудовая единица с квалификацией труда, его нормированием и оплатой. Она аккумулирует знания и умения конкретного человека (пользователя СППР) с интегрированными знаниями и умениями, заложенными в ПЭВМ [11].

1.2. Классификация программного обеспечения

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

К программному обеспечению относится также вся область деятельности по проектированию и разработке ПО:

- технология проектирования программ;

- методы тестирования программ;

- методы доказательства правильности программ;

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

- документирование программ;

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

Программное обеспечение – неотъемлемая часть компьютерной системы. Оно является логическим продолжением технических средств. Сфера применения конкретного компьютера определяется созданным для него ПО.

Сам по себе компьютер не обладает знаниями ни в одной области применения. Все эти знания сосредоточены в выполняемых на компьютерах программах.

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

Программы, работающие на компьютере, можно разделить на три категории:

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

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

- Вспомогательное ПО (инструментальные системы и утилиты).

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

Прикладное ПО. Для IBM PC разработаны и используются сотни тысяч различных прикладных программ для различных применений. Наиболее широко применяются программы:

- подготовки текстов (документов) на компьютере – редакторы текстов;

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

- обработки табличных данных – табличные процессоры;

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

Прикладная программа – это любая конкретная программа, способствующая решению какой-либо задачи в пределах данной проблемной области.

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

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

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

Наиболее часто используемые типы прикладных программ:

- Графические редакторы позволяют создавать и редактировать картинки на экране компьютера. Как правило, пользователю предоставляются возможности рисования линий, кривых, раскраски областей экрана, создания надписей различными шрифтами и т.д. Большинство редакторов позволяют обрабатывать изображения, полученные с помощью сканеров, а так же выводить полученные картинки в таком виде, чтобы они быть включены в документ, подготовленный с помощью текстового редактора или издательской системы.

- Системы деловой и научной графики позволяют наглядно представлять на экране различные данные и зависимости. Системы деловой графики дают возможность выводить на экран различные виды графиков и диаграмм (гистограммы, круговые и секторные диаграммы и т.д.).

- Системы управления базами данных (СУБД) позволяют управлять большими информационными массивами – базами данных. Наиболее простые системы этого вида позволяют обрабатывать на компьютере один массив информации, например персональную картотеку. Они обеспечивают ввод, поиск, сортировку записи, составление отчетов и т.д. С такими СУБД легко могут работать пользователи даже не высокой квалификации, так как все действия в них осуществляются с помощью меню и других диалоговых средств.

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

1. Системы автоматизированного проектирования (САПР) позволяют осуществлять черчение и конструирование различных механизмов с помощью компьютера.

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

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

4. Программы-оболочки. Весьма популярный класс системных программ составляют программы-оболочки. Они обеспечивают более удобный и наглядный способ общения с компьютером, чем с помощью командной строки DOS .Многие пользователи настолько привыкли к удобствам, предоставляемым своей любимой программой-оболочкой, что чувствуют себя без нее «не в своей тарелке». Наиболее популярными программами-оболочками являются Norton Commander, Xtree Pro Gold, PC Shell из комплекта PC Tools. В состав операционной системы MS DOS, начиная с версии 4.0, также входит собственная программа-оболочка Shell (впрочем, не очень популярная).

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

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

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

- расширенные средства для обмена информацией между программами.

Операционные оболочки упрощают создание графических программ, предоставляя для этого большое количество удобных средств, и расширяют возможности компьютера. Но платой за это являются повышенные требования к ресурсам. Так, для эффективной работы c Microsoft Windows необходим компьютер АТ/386, имеющий 4 Мбайта оперативной памяти. Наиболее популярной программой-надстройкой является Microsoft Windows, иногда используется Desq View и значительно реже – другие оболочки (GEM, Geo Works и др.).

Вспомогательные программы (утилиты) - к системным программам можно также отнести большое количество так называемых утилит, т.е. программ вспомогательного назначения. Часто утилиты объединяются в комплексы, наиболее популярны комплексы Norton Utilities, PC Tools Deluxe и Mace Utilities.

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

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

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

Программы для диагностики компьютера позволяют проверить конфигурацию компьютера (количество памяти, ее использование, типы дисков и так далее), а также проверить работоспособность устройств компьютера (прежде всего жестких дисков). Существует очень много программ подобного рода, однако это программы, которые, в основном, производят диагностику или позволяют проверить конфигурацию отдельных частей персонального компьютера. А программ, объединяющих в себе диагностику нескольких частей компьютера на сегодняшний день мало (SiSoftware Sandra, AIDA32, PCInfo v 1.0.1).

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

Программы для автономной печати позволяют распечатывать файлы на принтере параллельно с выполнением другой работы на компьютере [9].

1.3. Обзор аналогов

Самый распространенный, и пожалуй единственный серьезный аналог моего программного продукта это программный продукт SiSoftware Sandra. SiSoftware Sandra - (сокращение от System ANalyser, Diagnostic and Reporting Assistant) - это информационная и диагностическая программа. Она предоставляет практически всю информацию о вашем аппаратном и программном обеспечении (включая недокументированную), которая вам может понадобиться. Sandra похожа на многие другие подобные программы для Windows, однако, она старается превзойти их и показать то, что есть на самом деле, максимально объективно. Вы можете получить информацию о процессоре, чипсете, видео адаптере, портах, принтерах, звуковой карте, памяти, сети, процессах Windows, AGP, связях ODBC, USB2, 1394/Firewire, и т.д. Здесь разработчики описывали лишь преимущества данной программы, однако ничего не сказано было о ее недостатках, а их достаточно. Это и большой объем дискового пространства, занимаемого программой после ее установки (в версии 2004 более двенадцати мегабайт), и сравнительно медленная ее работа, особенно это проявляется в тестах, которые порой длятся по несколько минут, а не по пятнадцать секунд, как просит программа подождать пока запускаемый модуль тестируется, а при запуске теста локальных дисков программа зачастую и вовсе зависает, поскольку начинает потреблять для теста большое количество памяти, которой для самого теста может вовсе не хватить, это и большая нагрузка на центральный процессор, особенно во время запуска все тех же тестов, при этом процессор работает на пределе и его загрузка постоянно держится на уровне девяноста – ста процентов. Хоть в принципе для подобного рода программ это нормально, одна можно создать алгоритм, при котором программа не будет настолько требовательна к системным ресурсам.

Еще один аналог моего программного продукта это AIDA32 - Enterprise System Information. Все данные сгруппированы по разделам, а каждый раздел, в свою очередь, зачастую имеет несколько своих внутренних разделов, содержащих более специфичную информацию. Однако данный программный продукт менее распространен нежели SiSoftware Sandra, поскольку она более проста, в ней не так много модулей описания и тестирования модулей персонального компьютера, но в ней содержатся практически те же недостатки что и у SiSoftware Sandra, это и пять мегабайт на жестком диске после установки программы, и большая требовательность к системным ресурсам и небесплатность программного продукта.

2. Обзор интегральных средств

2.1. Методологии и технологии проектирования информационных систем

2.1.1. Общие требования к методологии и технологии

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

Технология проектирования определяется как совокупность трех составляющих:

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

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

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

На данный момент существует две модели разработки программного обеспечения. Сейчас более современной и лучшей моделью разработки является - спиральная (см. рис. 2.1.).

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

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

- технология должна поддерживать полный ЖЦ ПО;

- разработки ИС с заданным качеством и в установленное время;

Рис. 2.1. Спиральная модель разработки программного обеспечения.

Рис. 2.2. Представление технологической операции проектирования.

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

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

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

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

- технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

- технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

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

- стандарт проектирования;

- стандарт оформления проектной документации;

- стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

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

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

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

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

Стандарт оформления проектной документации должен устанавливать:

- комплектность, состав и структуру документации на каждой стадии проектирования;

- требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

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

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

- требования к настройке CASE- средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

- правила использования клавиатуры и мыши;

- правила оформления текстов помощи;

- перечень стандартных сообщений;

- правила обработки реакции пользователя [4].

2.2. Структурный подход к проектированию информационных систем

Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.

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

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

- принцип иерархического упорядочивания;

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

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

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

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

- принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

- SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

- DFD (Data Flow Diagrams) диаграммы потоков данных;

- ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы [1].


2.3. Примеры комплексов CASE-средств

В заключение приведу примеры комплексов CASE-средств обеспечивающих поддержку полного жизненного цикла программного обеспечения. Здесь хотелось бы еще раз отметить нецелесообразность сравнения отдельно взятых CASE-средств, поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ПО. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ПО. Сравниваться могут комплексы методологически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков. По мнению автора, на сегодняшний день наиболее развитым из всех поставляемых в России комплексов такого рода является комплекс технологий и инструментальных средств создания ИС, основанный на методологии и технологии DATARUN. В состав комплекса входят следующие инструментальные средства:

- CASE-средство Silverrun;

- средство разработки приложений JAM;

- мост Silverrun-RDM <-> JAM;

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

- менеджер транзакций Tuxedo;

- комплекс средств планирования и управления проектом SE Companion;

- комплекс средств конфигурационного управления PVCS;

- объектно-ориентированное CASE-средство Rational Rose;

- средство документирования SoDA [6].

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

- Vantage Team Builder for Uniface + Uniface (фирмы "DataX/Florin" и "ЛАНИТ");

- комплекс средств, поставляемых и используемых фирмой "ФОРС":

- CASE-средства Designer/2000 (основное), ERwin, Bpwin и Oowin (альтернативные);

- средства разработки приложений Developer/2000, ORACLE Power Objects (основные) и Usoft Developer (альтернативное);

- средство настройки и оптимизации ExplainSQL (Platinum);

- cредства администрирования и сопровождения SQLWatch, DBVision, SQL Spy, TSReorg и др. (Platinum);

- средство документирования ORACLE Book.

- комплекс средств на основе продуктов фирмы CENTURA:

- CASE-средства ERwin, Bpwin и Oowin (объектно-ориентированный анализ);

- средства разработки приложений SQLWindows и TeamWindows;

- средство тестирования и оптимизации приложений "клиент-сервер" SQLBench (ARC);

- средства эксплуатации и сопровождения Quest и Crystal Reports [8].


3. Анализ языков программирования

3.1. Обзор языков программирования

3.1.1. Языки программирования системного уровня

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

К концу 50-х годов начали появляться языки программирования более высокого уровня, такие как Lisp, Fortran, ALGOL. В них уже не было точного соответствия между языковыми конструкциями и машинными командами. Преобразование строк исходного кода в последовательности двоичных команд осуществлялось компилятором. Со временем их число пополнилось языками PL /1, Pascal, C, C++, Java. Все они менее эффективно используют аппаратуру по сравнению с языками ассемблера, но позволяет быстрее создавать приложения. В результате им удалось практически полностью вытеснить языки ассемблера при создании крупных приложений [2].

3.1.2. Языки программирования высокого уровня

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

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

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

Для описания структур управления программист может использовать также ключевые слова, как if, while; последовательности машинных команд, соответствующие этим описаниям компилятор генерирует динамически [5].

3.1.3. Языки описания сценариев

Языки описания сценариев, такие как Perl, Python, Rexx, Tcl, Visual Basic и языки оболочек UNIX, предполагают стиль программирования, весьма отличный от характерного для языков системного уровня. Они предназначаются не для написания приложения с “нуля”, а для комбинирования компонентов, набор которых создается заранее при помощи других языков. Например, Tcl, Visual Basic могут использоваться для построения пользовательских интерфейсов из имеющихся элементов управления, а языки описания сценариев для оболочек UNIX применяются для формирования “конвейеров” обработки потоков данных из набора стандартных фильтров. Языки описания сценариев часто применяются и для дополнения готовых компонентов новыми возможностями; однако эта деятельность редко охватывает создание сложных алгоритмов или структур данных, которые уже обычно бывают уже заложены в компоненты. Иногда языки описания сценариев даже называют связующими или языками системной интеграции.

Для языков описания сценариев характерно отсутствие типизации, которая только усложнила бы задачу соединения компонентов. Все элементы в них выглядят и функционируют одинаково и являются полностью взаимозаменяемыми. Например, в Tcl или Visual Basic переменная может содержать в одной точке программы строку, а в другой – целое число. Код и данные также часто бывают взаимозаменяемы. Например, Tcl, Visual Basic переменная может содержать в одной точке программы строку, а в другой - целое число. Код и данные также часто бывают взаимозаменяемы, так что программа может генерировать другую программу - и сразу же запускать ее исполнение. Обычно языки описания сценариев используют переменные строковых типов, которые обеспечивают единообразный механизм представления для различных сущностей.

Отсутствие в языке деления переменных на типы упрощает соединение компонентов между собой. Нет априорных ограничений на то, каким образом может использоваться тот или иной элемент, а все компоненты значения представляются в едином формате. Таким образом, компонент или значение могут быть использованы в любой ситуации; будучи спроектированы для одних способов применения, они могут оказаться задействованы совершенно иными, о которых их создатель никогда не помышлял. Например, в UNIX – оболочках работа любой программы – фильтра включает чтение данных из входного потока и запись их в выходной поток. Любые две такие программы могут быть связаны путем назначения выходного потока одной в качестве входного потока другой. Следующая команда оболочки представляет систему из трех фильтров, подсчитывающую в выделенном фрагменте текста строки, содержащие слово “scripting”:

Select

Анализ и разработка информационной системы, структура сети предприятия. Описание процесса разработки конфигураций и выявление потребностей в автоматизации функций. Средства разработки проектирования и архитектура базы данных. Разработка модели угроз.

  • 1. Создание информационной системы "План–меню" для автоматизации рабочего места заведующего производством

    Технико-экономическое обоснование разработки информационной системы "План-меню". Выбор технических средств и стандартного программного обеспечения. Проектирование структуры базы данных. Разработка и структура пользовательского интерфейса и ER-модели.

    курсовая работа, добавлен 07.05.2009

  • 2. Разработка информационной системы "Электронная записная книжка"

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

    курсовая работа, добавлен 09.04.2013

  • 3. Разработка информационной системы ОВД г. Донецка

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

    дипломная работа, добавлен 18.12.2010

  • 4. Разработка имитационной модели программного обеспечения информационной системы "Центр обслуживания абонентов"

    Моделирование вариантов объектно-ориентированных программных систем. Проектирование статический структуры, интерфейса, диаграмм компонентов и архитектуры приложения для разработки имитационной модели информационной системы "Центр обслуживания абонентов".

    дипломная работа, добавлен 24.10.2010

  • 5. Проектирование корпоративной информационной системы предприятия

    Разработка структуры корпоративной информационной системы ООО НПО "Мир": создание схемы адресации, системы доменных имен; выбор программной и аппаратной конфигураций клиентских станций и развернутых серверов. Расчет стоимости программного обеспечения.

    курсовая работа, добавлен 20.02.2013

  • 6. Разработка автоматизированной информационной системы учета для расчёта заработной платы ОАО РПТ "Авторемонтник"

    Выбор методологии проектирования и разработка информационной системы "Расчёт зарплаты" для предприятия ОАО РТП "Авторемонтник". Архитектурное проектирование базы данных информационной системы и разработка её интерфейса. Тестирование программного модуля.

    дипломная работа, добавлен 25.05.2014

  • 7. Разработка базы данных и интерфейса для системы, реализующей трансформацию высокоуровневого описания модели проекта в конструкции языка программирования

    Анализ предметной области, этапы проектирования автоматизированных информационных систем. Инструментальные системы разработки программного обеспечения. Роль CASE-средств в проектировании информационной модели. Логическая модель проектируемой базы данных.

    курсовая работа, добавлен 21.03.2011

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

    Создание сайта в сети Интернет для информирования студентов и преподавателей о проходящих конференциях. Разработка модели "как будет" с учетом внедрения системы автоматизации. Описание сценариев элементарных функций и физической модели базы данных.

    курсовая работа, добавлен 19.12.2015

  • 9. Разработка автоматизированной системы управления технологическим процессом

    Анализ информационных потоков. Разработка структуры таблиц базы данных. Выбор CASE-средства для проектирования информационной системы и среды программирования. Разработка программных модулей (программного обеспечения). Подготовка справочных баз данных.

    дипломная работа, добавлен 19.11.2013

  • 10. Разработка информационной системы для автоматизации работы отделений и приемной комиссии в среднем профессиональном учебном заведении

    Основы методологии проектирования информационной системы. Общая характеристика и классификация CASE-средств. Рассмотрение логической, функциональной и физической модели данных системы "Студент". Расчет трудоемкости разработки программного изделия.

    дипломная работа, добавлен 16.03.2012

  • Источник: http://allbest.ru/k-2c0b65625b3bd78b5c53b89521316c27.html
    .


    На рисунке 6 приведен водопадный процесс разработки с указанием результатов на каждом этапе.

    МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

    ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

    ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

    ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

    НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

    Кафедра Автоматизированных систем управления

    ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

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

    Казакова Никиты Евгеньевича

    Направление подготовки

    Информатика и вычислительная техника

    Руководитель

    Терещенко П.В.


    Реферат

    ТОВАР, УЧЕТ, СКЛАД, ЗАПАС, ПРЕДПРИЯТИЕ, ЗАКАЗ

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

    В экономическом разделе выполнен SWOT-анализ разработки системы и приведена смета затрат на ее рецензия на дипломную работу по юриспруденции договор купли-продажи разделе охраны труда рассмотрены условия хранения медикаментов и расчёт мощности вентилятора.


    Содержание

    Введение

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

    1.1 Обзор систем организации управления предприятия

    1.2 Характеристика объекта автоматизации

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

    2. Описание постановки комплекса задач системы

    2.1 Общая характеристика задач системы

    2.2 Выходная информация

    2.3 Как правильно писать заключение дипломной работы информация

    2.4 Технологические процесс функционирования системы в автоматизированном режиме

    2.5 Требования к программно-техническому обеспечению

    2.5.1 Комплекс технических средств

    2.5.2 Общесистемное программное обеспечение

    2.5.3 Выбор и обоснование инструментального средства

    3. Разработка информационного обеспечения системы

    3.1 Состав и структура таблиц базы данных системы

    3.2 Логическая модель взаимосвязи таблиц базы данных системы

    3.3 Информационная модель системы

    3.4 Описание алгоритмов и программ

    3.4.1 Описание алгоритма программного модуля расчёта

    гарантийного запаса товаров

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

    3.4.3 Описание алгоритма программного модуля формирование

    отчета «Объем продаж»

    3.4.4 Описание алгоритма программного разработка программного обеспечения на примере дипломная работа формирование отчета «Ведомость остатков»

    3.4.5 Описание алгоритма программного дипломная работа на тему социальные услуги формирование отчета «Списания»

    3.5 Контрольный пример

    4. Организационно экономическое обоснование дипломного проекта

    4.1 Целесообразность разработки с экономической точки зрения

    4.2 SWOT-анализ разработки

    4.3 Калькуляция себестоимости научно-технической продукции

    4.4. Отчисления на социальные нужды

    5. Раздел «Охрана труда»

    5.1 Требования безопасности к хранению медикаментов на аптечных складах

    5.2 Расчёт мощности вентилятора

    Заключение

    Список использованных источников

    Приложения


    Введение

    Управление товарными ресурсами в компании предполагает планирование и прогнозирование деятельности предприятия. Проведение анализа большого количества информации по истории продаж, поставок, товарных запасов, списаний и т.д. А также расчёт оптимальных размеров товарных запасов разработка программного обеспечения на примере дипломная работа дальнейшего планирования размеров и номенклатуры заказов поставок необходимых для поддержания эффективного функционирования склада. Оптимизация уровня товарных запасов на предприятии встает в связи проблемой содержания запасов, с одной стороны нужно избежать переполнения разработка программного обеспечения на примере дипломная работа на складах, и с другой стороны нежелательно допускать отсутствия необходимого товара длительное время. Одним из наиболее известных и эффективных методов анализа товарных запасов является формула Вильсона. А также распределение товаров на складах в зависимости от стабильности продаж, при помощи методов ABC - анализа.

    Объектом автоматизации является ЗАО «Аптека-Холдинг» - крупная компания на рынке фармацевтических препаратов. Компания занимается оптовой и розничной торговлей большой номенклатуры лекарственных средств, охватывающих весь спектр необходимых фармацевтических препаратов.

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

    В соответствии с поставленной целью можно сформулировать следующие задачи разработки системы:

    · системный анализ работы логистика;

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

    · определение состава автоматизируемых задач;

    · постановка задач системы;

    · разработка технологии функционирования системы в условиях автоматизированного управления;

    · определение структуры базы данных системы, построение информационной модели системы;

    · построение интерфейса взаимодействия пользователя с системой;

    · разработка алгоритмов;

    · отладка и тестирование программного обеспечения системы;

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


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

    В конце 60-х годов, в связи с бурным развитием вычислительной техники, ее возможности перестали быть востребуемы только отдельными наукоёмкими отраслями, компьютерные системы прочно входили в повседневную деловую жизнь. Повсюду начались активные попытки оптимальной автоматизации информатизации бизнеса, создавались новые концепции управления и совершенствовались уже существующие. Основными целями автоматизации производственных компаний являлись: точный расчет актуальной себестоимости продукции, ее анализ, понижение затрат в процессе производства и повышение производительности в целом, благодаря эффективному планированию производственных мощностей и ресурсов. Результатом оптимизации этих параметров являлись понижение конечной цены готовых изделий и повышение общей производительности, что соответственно немедленно отражалось на конкурентоспособности и рентабельности компании. В результате поиска решений в области автоматизации производственных систем родилась концепция планирования потребностей в материалах (MRP). По сути, MRP-методология представляет собой алгоритм оптимального управления заказами на готовую продукцию, производством и запасами сырья и материалов, реализуемый с помощью компьютерной системы. Другими словами, MRP система позволяла оптимально загружать производственные мощности, и при этом закупать именно столько материалов и сырья, сколько необходимо для выполнения текущего плана заказов именно столько, сколько возможно обработать за соответствующий цикл производства. Тем самым планирование текущей потребности в материалах позволяло разгрузить склады как и сырья и комплектующих (сырье и комплектующие закупались ровно в том объеме, который можно обработать за один производственный цикл и поступались прямо в производственные цеха), так и склады готовой продукции (производство шло в строгом соответствии с принятым планом заказов, и продукция, относящаяся к текущему заказу, должна быть произведена ровно к сроку его исполнения (отгрузки)). Собственно методология MRP является реализацией двух известных принципов JIT (Just In Time – Вовремя заказать) и KanBan (Вовремя произвести). Разумеется, идеальная реализация концепции MRP невыполнима в реальной жизни. Например, из-за возможности срыва сроков поставок по различным причинам и последующей остановки производства в результате этого. Поэтому в жизненных реализациях MRP-систем на каждый случай предусмотрен заранее определенный страховой запас сырья и комплектующих (safety stock), объем которого определяется компетентным руководством компании.

    После появления концепции MRP, казалось бы, все основные проблемы производства были решены, активно создавались и продавались компьютерные программы, реализующие принципы этой концепции. Однако в процессе дальнейшего анализа существующей ситуации в мировом бизнесе и ее развития, выяснилось, что всю большую составляющую себестоимости продукции занимают затраты напрямую не связанные с процессом и объемом производства. В связи с растущей от года к году конкуренцией, конечные потребители продукции становятся все более “избалованными”, ощутимо увеличиваются затраты на рекламу и маркетинг, уменьшается жизненный цикл изделий. Всё это требует пересмотрения взглядов на планирование коммерческой деятельности. Отныне нужно не “что-то производить и стараться потом продать”, а “стараться производить, то, что продается”. Таким образом, маркетинг и планирование продаж должны быть непосредственно связаны с планированием производства.

    В 90-х курсовая по бизнес планированию на примере предприятия 2017 методы MRP были модифицированы и улучшены, в связи с этим появились такие системы, как MRP II (Manufacturing Resource Planning) – это планирование производственных ресурсов и ERP (Enterprise Resource Planning) – это планирование потребностей предприятий средства выразительности в рекламе дипломная работа материалах. Преимущества, даваемые этими методами, состоят в минимизации издержек, связанных со складскими запасами сырья, комплектующих, полуфабрикатов и прочего, а также с аналогичными запасами, находящимися на различных участках непосредственно в производстве.

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

    Мировой опыт показывает, что успеха достигают те компании, которые балансируют производственные, коммерческие и финансовые цели. Рассматривают предприятие как единую производственно-сбытовую систему (ПСС), связывающую воедино такие сферы как: маркетинг – создание новых изделий – снабжение – производство – сбыт – доставка продукции потребителю – сервисное обслуживание, используют промышленные стандарты MRP/ERP в качестве базовой бизнес - модели, нацеленной на достижение экономической эффективности.

    Рассмотрим концепцию MRP II поподробнее, так как на основе этой концепции будет проектироваться дипломный проект.

    В системах класса MRP II содержатся следующие функции производственно - сбытовой системы:

    - По математическому развитию у дошкольников продаж и производства (Sales and Operation Planning);

    - Управление спросом (Demand Разработка программного обеспечения на примере дипломная работа Составление плана курсовик по перепланировке двух квартир в одну разработка программного обеспечения на примере дипломная работа Production Scheduling);

    - Планирование материальных потребностей (MRP - Material Requirement Planning);

    - Управление запасами (Inventory Transaction Subsystem);

    - Управление плановыми поставками (Scheduled Receipts Subsystem);

    - Планирование производственных мощностей (CRP – Capacity Requirement Planning);

    - Материально техническое снабжение (Purchasing);

    - Планирование ресурсов для распределения (DRP – Distribution Resource Planning);

    - Планирование и контроль производственных операций (Tooling Planning and Control);

    - Управление финансами (Financial Planning);

    - Моделирование для производственной программы (Simulation);

    - Оценка результатов деятельности (Performance Measurement).

    Управление запасами, эта подсистема обеспечивает реализацию следующих функций:

    - Inventory Control – мониторинг запасов;

    - Physical Inventory – регулирование инвентаризация складских остатков.

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

    Управления снабжением, эта подсистема реализует следующие функции:

    Purchase Orders - заказы на закупку;

    Supplier Schedules - график поставок;

    MRP - планирование потребности в материалах, понимаемое как управление заявками на закупку.

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

    Результаты использования интегрированных систем стандарта MRP II:

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

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

    - решение задач оптимизации производственных и материальных потоков;

    - реальное сокращение материальных ресурсов на складах;

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

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

    - значительное сокращение непроизводственных затрат;

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

    Применение MRP технологий становится стандартным на большинстве предприятий. Влияние на бизнес качества приложений MRP/ERP огромное. Использование MRP содействует прогнозированию и планированию, что может обеспечить значительное сокращение издержек и улучшение процесса производства. Производители, которые успешно внедрили системы MRP, имеют: уменьшенные складские запасы, уменьшенное время выхода на рынок новых продуктов и конечно же увеличение прибыльности.

    На мировом рынке сейчас предлагается свыше 500 систем класса MRP II-ERP. Рынок бурно растет - на 35% - 40% каждый год. В настоящее примеры рецензий на по таможенному делу в России присутствуют около десятка западных систем, таких как: BAAN IV, SAP R3, ORACLE Applications, QAD MFG/PRO и несколько отечественные информационные системы – СПЕКТР, Практик–А, Тектон, которые можно отнести к корпоративным. Типовая стоимость проекта по внедрению такой системы составляет от 50 до 250 тысяч долларов для тиражно - заказных систем, и до 20 тысяч - для тиражируемых, или «коробочных».

    На где сшить дипломную работу в москве момент в состав MPR систем входит множество методов, включая методы расчёта оптимальных размеров товарных запасов их распределения, а также методы расчёта оптимальных размеров заказов. В данной работе мы воспользуемся несколькими из таких методов – формулой расчёта размера оптимальных размеров заказов - формулой Вильсона, и методов АВС и XYZ- анализов для распределения товаров на складе.

    1.2 Характеристика объекта автоматизации

    ЗАО «Аптека-Холдинг» - крупная фармацевтическая компания, занимающаяся реализацией и производством большого ассортимента лекарственных препаратов. Компания является одним из крупнейших в Сибири дистрибьютором крупных Российских иностранных заводов по производству фармацевтических материалов. Также ЗАО «Аптека-Холдинг» имеет ряд филиалов в городах Сибирского региона. В компании работают: региональный департамент сбыта, корпоративный департамент сбыта и городской (Новосибирский) департамент сбыта. Статус официальных представителей заводов позволяет вести гибкую ценовую политику с клиентами, формировать большие объемы поставок и варьировать сроки поставок.

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

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

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

    Департамент сбыта – занимается приёмом разработка программного обеспечения на примере дипломная работа от департаментов сбыта регионального и корпоративного назначения, а также от частных лиц. При приёме заказа оператор проверяется наличие товаров на складах в нужном объёме и вписывает их в расходную накладную. После формирования заказа, выписываются необходимые документы на получение заказа для клиента. Затем пакет документов отправляется на склад.

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

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

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

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

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

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

    На рисунке 1.1 введены следующие обозначения:

    Ф1 – филиал №1;

    Ф2 – филиал №2;

    Фn – филиал №n;

    Корпоративный ДС – корпоративный департамент сбыта;

    Региональный ДС – региональный департамент сбыта;

    1 – заявка на формирование заказа от покупателя;

    2 – заявка на формирование заказа от филиалов, департаментов сбыта;

    3 – расходная накладная;

    4 – счёт, счёт-фактура клиенту;

    5 – сведения о продажах, поставках и об остатках на складе;

    6 – заявка поставщикам на оформление заказа от департамента поставок;

    7 – приходная накладная, счет-фактура;

    8 – сведения о поставках.



    2. Описание постановки задач системы

    2.1 Общая характеристика задач

    На разработка программного обеспечения на примере дипломная работа анализа функционирования компании можно выделить следующие задачи:

    - «Учет прихода товара на склад» (Z1);

    - «Учет расхода товара со склада» (Z2);

    - «Учет инвентаризации товара» (Z3);

    - «Формирование оптимального размера заказов» (Z4);

    - «Распределение товара на складе» (Z5);

    - «Формирование отчета «Объем продаж за период»» (Z6);

    - «Формирование отчета «Ведомость остатков»» (Z7);

    - «Ведение справочников системы» (Z8).

    Задачу Z1целесообразно разделить на подзадачи:

    - «Добавление записей в справочник «Поставки»» (Z11);

    - «Добавление новых видов товаров» (Z12);

    - «Добавление новых групп товаров» (Z13);

    - «Добавление новых поставщиков» (Z14);

    - «Формирование отчета «Приходная ведомость»» (Z15).

    Задачу Z2целесообразно разделить на подзадачи:

    - «Учет списанного товара со склада» (Z21);

    - «Учет проданного товара со склада» (Z22)

    - «Формирование отчета «Ведомость остатков»» (Z23).

    Задачу Z3целесообразно разделить на следующие подзадачи:

    - «Введение данных по инвентаризации» (Z31);

    - «Формирование отчета «Акт о недостаче» (Z32);

    Задачу Z4можно представить как:

    - «Расчёт затрат на хранение товарных запасов» (Z41);

    - «Определение гарантийного запаса товаров» (Z42);

    - «Формирование оптимального размера заказов» (Z43);

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

    Ежедневно на склады поставляется товар различной номенклатуры от разных поставщиков (Z1). Все поставки необходимо фиксировать и заносить сведения в БД (Z11), такие как наименование товара, объем поставки, дата поставки, фасовка, поставщик. Так же периодически привозят новые товары (Z12), относящиеся к новым группам товаров (Z13), от новых поставщиков (Z14). Следовательно, эти позиции необходимо добавить в справочники системы (БД). Для коррекции приходной накладной и проверке введенных данных необходимо сформировать отчет «Приходная ведомость» (Z16).

    Со склада идут постоянные отгрузки товаров покупателям (Z2), а также формирование машин для региональных, городских заказчиков и филиалов. Необходимо вести учёт отгруженных товаров (Z21), вносить данные о них в БД, такие как наименование товара, объем отгрузки, дата отгрузки, фасовка, заказчик. Иногда некоторые товары со склада списывают, по причине заводского брака, порчи и невостребованности товара. При этом также заносятся сведения в БД (Z22) о списанных товарах, причине списания, объём списания, дата списания. После занесения данных в БД формируется отчет «Ведомость остатков».

    Один раз в год на складе проводится инвентаризация (Z3) товаров на складах. Для корректной работы системы необходимо учитывать результаты инвентаризации и заносить их в БД (Z31). Для сверки разработка программного обеспечения на примере дипломная работа ведомости» с данными, хранящимися в БД, необходимо дипломная работа система питания ваз 2108 отчет «Акт о недостаче» (Z32), в зависимости от результатов сопоставления «Инвентаризационной ведомости» с «Ведомостью остатков», сформированной по данным из БД.

    Расчёт затрат на хранение товарных запасов (Z41) лежит в основе оптимизации уровня запасов товаров предприятия на плановый период. Для эффективного функционирования складов заказы желательно должны быть большими их должно быть не много (Рис. 2.1), следовательно нужно достичь наименьших затрат проект шиноремонтного участка атп на 298 автомобилей содержание запасов, путём оптимизации размеров заказов. Критерием оптимизации при этом является, как правило, минимум совокупных затрат, связанных с запасом.

    Рисунок 2.1 Зависимость среднего уровня запасов от размеров заказов.

    В состав общих затрат по созданию и поддержанию запасов входят:

    1) затраты на хранение запаса;

    2) стоимость размещения заказа;

    3) стоимость закупки партии, восполняющей запас, или стоимость заказа.

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

    Общепринятым подходом к расчету среднего уровня запаса является то, что средний уровень запаса при восполнении его партиями по Q единиц равен половине этой величины, то есть Q/2. Следовательно, формула расчёта затрат на хранение будет иметь вид:


    T = Q/2*I + S/Q*A + C*S, где (2.1)

    T – общие затраты на создание и поддержание запаса;

    Q – размер заказа, восполняющего запас;

    I – затраты на хранение единицы товара в плановом периоде времени;

    S – потребность в запасе в плановом периоде;

    A – стоимость размещения одного заказа;

    С – цена единицы запаса.

    В общем виде общие затраты можно представить как:

    T = Затраты на хранение + Стоимость размещения заказа + Цена заказа

    Тогда общая стоимость размещения заказа будет рассчитываться разработка программного обеспечения на примере дипломная работа образом, по формуле Вильсона:

    , где (2.2)

    Q* - оптимальный размер заказа;

    I – затраты на хранение единицы товара в плановом периоде времени;

    S – потребность в запасе в плановом периоде;

    A – стоимость размещения одного заказа;

    С – цена единицы запаса.

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

    R = (tn+ tз)* Pдн- P0где, (2.3)

    tn– время поставки;

    tз– возможная задержка поставки;

    Pдн– ожидаемое дневное потребление товара;

    P0– ожидаемое потребление за время дипломная работа строительства эксплуатации зданий и сооружений с чертежами рассчитывается как, потребность в товаре за период - S/T

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

    где, (2.4)

    Si– потребность в запасе i-го наименования в плановом периоде;

    А – стоимость размещения одного заказа;

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

    – вектор затрат на хранение единицы запаса различных наименований в плановом периоде времени (денежные единицы измерения/единица запаса); включает в себя множество чисел, соответствующее количеству наименований товаров в поставке; например, вектор со значениями (28; 32; 30; 40) соответствует работе с четырьмя наименованиями товаров в одном заказе; при этом затраты на хранение на единицу запаса товара первого наименования составляют 28 единиц, второго - 32 единицы и т. д.;

    – произведение векторов, которое рассчитывается в данном случае как сумма произведений потребности в запасах на плановый период времени и затрат на хранение единицы запасов соответствующего наименования (в рассматриваемом примере: 5*28+7*32+10*30+12*40 = 1144 единицы).

    Также некоторые поставщики дают скидку на большие оптовые закупки. Следовательно, чем разработка программного обеспечения на примере дипломная работа объём заказа, тем ниже закупочные цены на приобретаемый товар. Каждой цене соответствует определённый диапазон объёма товаров. Для расчёта данного случая, можно применить следующую модификацию формулы Вильсона:

    где, (2.5)

    I – затраты на хранение единицы товара в плановом периоде времени;

    S – потребность в запасе в плановом периоде;

    A – стоимость размещения одного заказа;

    i – доля цены продукции, приходящейся на затраты по хранению;

    С – цена единицы запаса.

    Для распределения товара на складе (Z5) воспользуемся методами анализа товарного запаса на складе. Одним из наиболее известных методов является АВС – анализ. Идея АВС – анализа основана на принципе Парето, который формулируется следующим образом: «За большинство возможных результатов отвечает относительное небольшое число причин». В настоящее время этот принцип широко известен как «правило 20 на 80».

    АВС – анализ будем проводить по объему продаж за период. В результате получим 3 группы товаров:

    - группа А – товар, который лучше всего продается; эта группа составляет 20% ассортимента и 49% общего объема продаж;

    - группа В – товар, который хорошо продается; эта группа составляет 30% ассортимента и 30% общего объема продаж;

    - группа С – товар этой группы составляет 50% ассортимента и дипломные работы о торгово промышленных работах общего объема продаж; в эту группу попадает титульный лист для дипломной работы образец институт «ассортиментный хвост».

    Нередко АВС – анализ разработка программного обеспечения на примере дипломная работа в совокупности с XYZ – анализом. Основная идея XYZ – анализа состоит в группировании товара по однородности анализируемых параметров, другими словами по коэффициенту вариации.

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

    Коэффициент вариации рассчитывается по формуле (2.6).

    , (2.6)

    где ν – коэффициент вариации;

    σ – среднее квадратическое (стандартное) отклонение;

    - среднее значение.

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

    , (2.7)


    где- значение i-го периода;

    - среднее значение за n периодов;

    n – количество периодов.

    При проведении XYZ – анализа товары группируются по величине коэффициента вариации. В группу Х попадают товары с коэффициентом вариации меньше 10%. В группу Y – товары с коэффициентом вариации от 10% до 25%. И в группу Z – товары с коэффициентом вариации более 25%.

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

    При комплексном анализе состояния системы управления товарными ресурсами наиболее продуктивно является совмещение результатов АВС – и XYZ – анализов.

    При совмещении результатов определяется девять групп товаров. Группы товаров представлены в таблице 2.1.

    Таблица 2.1- Группы товаров при совмещении АВС – и XYZ – анализов

    Товары групп А и В обеспечивают основной товарооборот компании, поэтому необходимо контролировать постоянное их наличие на складе. Товары групп A и B необходимо распределить по складу, таким образом, чтобы доступ к ним был наиболее быстрый и удобный, для более быстрой отгрузки товаров.

    Товары группы АХ и ВХ отличает высокий товарооборот и стабильность. Необходимо обеспечить постоянное наличие данного товара, но для этого не требуется создавать избыточный страховой запас, так как расход товаров этой группы стабилен и хорошо прогнозируется.

    Товары группы АY и ВY при высоком товарообороте имеют недостаточную стабильность расхода, и, как следствие, для обеспечения постоянного наличия товаров на складе - нужно увеличить страховой запас.

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

    Товары группы Разработка программного обеспечения на примере дипломная работа составляют до 80% ассортимента компании. Применение XYZ - анализа позволяет сильно сократить время, которое менеджер тратит на управление и контроль над товарами данной группы.

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

    По товарам группы CY можно перейти на систему с постоянной суммой (объемом) заказа, но при этом формировать страховой запас, исходя из имеющихся у компании финансовых возможностей.

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

    Итак, использование совмещенного АВС – и XYZ – анализа позволит:

    - повысить эффективность системы управления товарными ресурсами;

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

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

    - выявить приоритеты для размещения товаров на складе;

    - перераспределить усилия персонала в зависимости от квалификации имеющегося опыта.

    По проведенным анализам каждому товару присваивается приоритет, на разработка программного обеспечения на примере дипломная работа которого данный товар «находит» свое место на складе. Склад делится на несколько зон. Товары группы A должны лежать в первой зоне, которая находится ближе к входу. Причем товар группы X имеет преимущество перед товаром группы Y и Z в размещении ближе к входу, к примеру товары группы Х лежат на первом ярусе, а товары группы Y и Z выше. Товар разработка программного обеспечения на примере дипломная работа B размещается во 2 зоне склада. А в заключение дипломной работы внесены изменения как пишется категории C соответственно размещается в 3 зоне, в самом конце склада. Этот алгоритм позволяет минимизировать перемещения товара, связанные с пополнением ячеек комплектации и подбора товаров для формирования заказов.

    Отчеты «Объем продаж за период» (Z6), «Ведомость остатков» (Z7) формируются по запросу пользователя на основе данных из БД о разработка программного обеспечения на примере дипломная работа, поступлениях и списаниях товаров со складов по конкретному товару, группе товаров, складу за выбранный период.

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

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

    Рисунок 2.3 – Схема информационной взаимосвязи задач системы

    2.2 Выходная информация

    Выходные документы формируются в процессе работы системы. Перечень этих документов приведен в таблице 2.2. Формы выходных документов содержатся в приложении А.

    Таблица разработка программного обеспечения на примере дипломная работа – Описание выходных документов

    Наименование

    документа

    Обозначение

    документа

    Периодичность формирования

    Получатель

    Приходная ведомость

    D1

    По приходу товара на склад

    Логистик склада

    Ведомость

    остатков

    D2

    По отгрузки или списании разработка программного обеспечения на примере дипломная работа и по необходимости

    Логистик склада

    Наименование

    документа

    Обозначение

    документа

    Периодичность формирования

    Получатель

    Акт о недостаче

    D3

    При проведении инвентаризации

    Логистик склада

    Бланк заказа

    D4

    При формировании

    заказа

    Логистик склада

    Объем продаж за период

    D5

    По необходимости

    Логистик склада

    Списания со склада

    за период

    D6

    По необходимости

    Логистик склада

    Справочные данные

    D7

    По необходимости

    Логистик склада

    2.3 Входная информация

    В процессе обследования объекта автоматизации была выявлена входная информация, необходимая для решения поставленных задач и получения результатов. Перечень и описание входных документов представлен в таблице 2.3. Формы входных документов приведены в приложении А.

    Таблица 2.3 – Описание входных документов

    Наименование документа

    Обозначение документа

    Периодичность

    поступления

    Источник информации

    Приходная накладная

    Д1

    При поставке товаров

    Поставщики

    Расходная накладная

    Д2

    При формировании заказа от клиента

    Департамент

    сбыта

    Акт на списание

    Д3

    В случае списания товара со склада

    Кладовщик

    Инвентаризационная ведомость

    Д4

    При проведении инвентаризации

    Комиссия по инвентаризации


    2.4 Технологические процесс функционирования системы в автоматизированном режиме

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

    Рассмотрим процесс функционирования системы в автоматизированном режиме. На склад стекается следующая информация: приходная накладная от поставщиков, когда приходит товар на склад (Д1); из департамента сбыта приходит расходная накладная (Д2) при формировании заказа от клиента; от кладовщиков складов в случае списаний со склада приходит акт на списание (Д3); от комиссии по инвентаризации приходит документ «Инвентаризационная ведомость» (Д4) при проведении инвентаризации на складе. Все сведения из указанных документов заносятся в базу данных. Системой осуществляется контроль данных. Если правильность данных не подтверждается, то производится корректировка введенных данных.

    Последовательность обработки информации отображена на рисунке 2.4.

    Машинная обработка заключатся в формировании бланка заказа товаров, отчетов «Приходная ведомость», «Акт о недостаче», «Объем продаж», «Ведомость остатков». На основании этих расчетов производится учёт товаров на складе и задание на формирование заказа. Результаты машинной обработки заносятся в базу данных, при необходимости отображаются на дисплее и выводятся на принтер.


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


    2.5 Требования к программно-техническому обеспечению

    Для нормального функционирования системы выдвигаются следующие требования к программно-техническому обеспечению и комплексу технических средств.

    2.5.1 Комплекс технических средств

    Для эксплуатации разрабатываемой системы предъявляются следующие

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

    - объем оперативной памяти 128 Мб;

    - объем жесткого диска 20 Гб;

    - частота процессора 600 МГц.

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

    В связи с этим для работы с системой рекомендуются следующие характеристики технического оснащения:

    - объем оперативной памяти 256 Мб и выше;

    - объем жесткого диска 40 Гб;

    - частота процессора 800-1000 МГц.

    - Дополнительные специальные требования к конфигурации ПК:

    - дисковод 3,5";

    - клавиатура и манипулятор типа «мышь» для управления в программе;

    - принтер формата А4 для печати выходных документов;

    - цветной монитор.

    2.5.2 Общесистемное программное обеспечение

    Данный программный продукт может функционировать в среде WINDOWS 98/NT/2000/XP и выше. С появлением операционной системы WINDOWS появились широкие возможности для создания программных продуктов. Система WINDOWS обеспечивает многозадачный графический интерфейс пользователя (Graphical User Interface - GUI), который способствует написанию интерактивных программ. Эта система представляет собой тип операционной системы, оптимизированной для взаимодействия человека и машины.

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

    2.5.3 Выбор и обоснование инструментального средства

    В качестве инструментального средства для создания программы был выбран пакет C++Builder 6.0 для операционной системы WINDOWS.

    C++Builder продукт корпорации Inprise, более известной как Borland International, предназначенный для быстрой разработки приложений (RAD - Rapid Application Development) на языке С++.

    C++Builder - мощная система визуального объектно-ориентированного проектирования, позволяющая решать множество задач, в частности:

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

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

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

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

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

    - множество других задач.

    С помощью C++Builder можно создавать WINDOWS - программы на С++ быстрее и проще, чем когда-либо ранее. Возможно создавать как консольные приложения Win32, так использовать графический интерфейс пользователя (GUI - Graphical User Interface). Это означает, создание интерфейса пользователя (меню, диалоговые окна, кнопки разработка программного обеспечения на примере дипломная работа т.д.), используя технику drag-and-drop. При этом не возникает потерь в скорости выполнения темы дипломных работ по нефтехимии, потому что вся мощь языка С++ по-прежнему остается в распоряжении разработчика. C++Builder поддерживает основные принципы объектно-ориентированного программирования - инкапсуляцию, полиморфизм и множественное наследование, а также последние расширения языка С++. Сам по себе язык C++ не является простым даже для профессионала, поэтому в C++Builder многое сделано для того, чтобы скрыть некоторые низкоуровневые детали, которые составляют «внутренности» Windows программ.

    C++Builder обеспечивает высокое быстродействие при компиляции и разработка программного обеспечения на примере дипломная работа 32-разрядных приложений для современных операционных систем Windows 95/98/NT/XP, включая системы взаимодействия клиент-сервер. Результирующие программы оптимизированы с по бухгалтерскому учету учет расчетов с поставщиками и подрядчиками зрения скорости выполнения и затрат памяти. Удобный отладчик (с ассемблерным окном прокрутки, пошаговым исполнением, точками остановки, трассировкой и т.д.) полностью интегрирован в среду C++Builder. Дизайнер форм, редактор кода, инспектор объектов и другие средства остаются доступными во время работы программы, поэтому вносить изменения можно в процессе отладки.

    С++Builder поддерживает связь с различными базами данных 3 видов: dBase и Paradox; Sybase, Oracle, InterBase и Informix; Excel, Access, Fох Pro и Btrieve.

    Механизм BDE (Borland Database Engine) придает обслуживанию связей с базами данных удивительную простоту и выбрать тему дипломной работы по маркетингу. Проводник Database Explorer позволяет изображать связи и объекты баз данных в графическом виде.

    Справочная служба C++Builder содержит полное описание каждого управляющего компонента, включая списки свойств и методов, а также многочисленные примеры.

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

    - Включение данных из различных источников. Access 2003 поддерживает различные форматы данных, в том числе XML, OLE, ODBC и формат служб Microsoft Windows® SharePoint™ Services.

    - Связи между бизнес-системами. Можно связать таблицы таким образом, чтобы одновременно получать доступ к данным из различных баз, работая с формами, отчетами и страницами доступа к данным в Access 2003. Кроме того, можно связывать таблицы из других баз данных Access, электронных таблиц Microsoft Excel, источников данных ODBC, баз данных Microsoft SQL Server™ и других источников.

    - Максимально эффективное использование корпоративных данных. Можно включить данные Microsoft SQL Server в решения Access. Используйте конструктор сохраненных процедур для создания изменения простых процедур, сохраняемых в SQL Server.


    3. Разработка отправляю вам дипломную работу на проверку обеспечения

    3.1 Состав и структура таблиц базы данных системы

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

    «Наименования товаров» - справочная таблица (см. таблицу 3.2), содержащая перечень товаров, находящихся на складах.

    «Группы товаров» - справочная таблица (см. таблицу 3.3), содержащая наименования разработка программного обеспечения на примере дипломная работа товаров, разработка программного обеспечения на примере дипломная работа которые разбит товар.

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

    «Должности» - справочная таблица (см. таблицу 3.5), содержащая перечень должностей сотрудников склада.

    «Клиенты» - таблица (см. таблицу 3.6), в которой содержится информация по всем клиентам предприятия, включая клиентов от филиалов, корпоративного ДС и городского ДС. Для каждого клиента указаны фамилия, имя, отчество, документ, удостоверяющий личность, организация, должность, контактный телефон, код банка, расчётный счёт, сведения о заказах.

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

    «Поставки» - таблица (см. таблицу 3.8), в которой хранится информация по товарам, полученным на склад учебный отпуск к дипломной работе образец поставщиков. Каждый приход товаров отображается в этой таблице со следующей информацией: наименование товара, поступившего на склад, фасовка товара, дата прихода товара, номер приходной накладной, объем прихода и сотрудник, принявший товар.

    «Заказы» - таблица (см. таблицу 3.9), в которой хранится информация по всем заказам. По каждому заказу указаны дата заказа, дата поставки, объём заказа, наименования товаров, цена по каждой группе товаров, общая цена заказа, сотрудник оформивший заказ.

    «Поставщики» - справочная таблица (см. таблицу 3.10), содержащая информацию о поставщиках товаров работающих с компанией. Для каждого поставщика указано наименование поставщика, адрес, телефон для связи, контактное лицо, код банка, расчётный счёт, сведения о поставках.

    «Банки» работа государственных органов с обращениями граждан таблица (см. таблицу 3.11), в которой содержится информация о банках работающих с компанией. Для каждого банка указаны его название, контактное лицо, контактный телефон, расчетный счёт, ИНН, БИК, КПП, и адрес.

    «Списания» - таблица (см. таблицу 3.12) отображает все списания товаров со склада: какой товар был списан, в какой фасовке, когда, номер документа на списание, ответственное лицо и причина списания.

    «Причины списания товаров» - справочная таблица (см. таблицу 3.13), содержащая перечень причин списания товаров со складов.

    «Инвентаризация» - таблица (см. таблицу 3.14), содержащая информацию о проведенных инвентаризациях. По каждой инвентаризации формируются записи в эту таблицу. Записываются перечень инвентаризуемых товаров с указанием их наименования и количества.

    Таблица 3.1 – Структура таблицы «Товар»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Код товара

    Id_tov

    Счетчик

    Код группы товара

    Id_group

    Длинное целое число

    Код поставщика

    Id_post

    Длинное целое число

    Цена товара

    Zena_tov

    Действительное число

    Затраты на хранение товара

    Zatr

    Действительное число

    Стоимость размещения единицы в заказе

    Stoim

    Действительное число

    Таблица 3.2 – Структура таблицы «Наименования товаров»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Код товара

    Id_tov

    Счетчик

    Наименование товара

    Tov

    Строка

    100

    Таблица 3.3 – Структура таблицы «Группы товаров»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Код группы товаров

    Id_group

    Счетчик

    Наименование группы товаров

    Group

    Строка

    50

    Таблица 3.4 – Структура таблицы «Сотрудники»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Код сотрудника

    Id_sotrud

    Счетчик

    Фамилия сотрудника

    Surname

    Строка

    30

    Имя сотрудника

    Name

    Строка

    30

    Отчество сотрудника

    Patronymic

    Строка

    30

    Дата рождения сотрудника

    Birth

    Дата

    Код должности

    Id_dolj

    Длинное целое число

    Дата приема на работу

    Date

    Дата

    Таблица 3.5 – Структура таблицы «Должности»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Код должности

    Id_dolj

    Счетчик

    Наименование должности

    Dolj

    Строка

    50

    Таблица 3.6 – Структура таблицы «Клиенты»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Код клиента

    Id_klient

    Счетчик

    Фамилия клиента

    Surname

    Строка

    30

    Имя клиента

    Name

    Строка

    30

    Отчество клиента

    Patronymic

    Строка

    30

    Название организации

    Org

    Строка

    30

    Код должности

    Id_dolj

    Длинное целое число

    Расчётный счёт

    Schet

    Действительное число

    Контактный телефон

    Tel

    Действительное число

    Заказы клиента

    N_zak

    Действительное число

    Таблица 3.7 – Структура таблицы «Продажи»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Номер записи

    N

    Счетчик

    Код товара

    Id_tov

    Длинное целое число

    Дата продажи товара

    Date

    Дата

    Номер расходной накладной

    N_doc

    Строка

    10

    Количество на тему аттестация рабочих мест число

    Код сотрудника, отпустившего товар

    Id_sotrud

    Длинное целое число

    Таблица 3.8 – Структура таблицы «Поставки»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Номер записи

    N

    Счетчик

    Код товара

    Id_tov

    Длинное целое число

    Дата поставки товара

    Date

    Дата

    Номер приходной накладной

    N_doc

    Строка

    10

    Количество поставленного товара

    Amount

    Действительное число

    Код сотрудника, принявший товар

    Id_sotrud

    Длинное целое число

    Код поставщика

    Id_post

    Длинное целое число

    Таблица 3.9 – Структура таблицы «Заказы»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Номер записи

    N

    Счетчик

    Код товара

    Id_tov

    Длинное целое число

    Дата заказа товара

    Date

    Дата

    Номер бланка заказа

    N_zak

    Строка

    10

    Код поставщика

    Id_post

    Длинное целое число

    Количество товара

    Kolvo

    Действительное число

    Код сотрудника, отпустившего товар

    Id_sotr

    Длинное целое число

    Стоимость заказа

    Zena

    Действительное число

    Затраты на создание заказа

    Zatr_zak

    Действительное число

    Таблица 3.10 – Структура таблицы «Поставщики»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Код поставщика

    Id_post

    Счетчик

    Наименование поставщика

    Post

    Строка

    50

    Контактное лицо

    FIO

    Строка

    50

    Телефон для связи

    Tel

    Строка

    25

    Код банка

    Id_bank

    Длинное целое число

    Расчётный счёт

    Schet

    Действительное число

    Среднее время поставки

    Tpost

    Действительное число

    Среднее время задержки поставки

    Zpost

    Действительное число

    Таблица 3.11 – Структура таблицы «Банки»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Код банка

    Id_bank

    Счетчик

    Наименование банка

    Bank

    Строка

    50

    Контактное лицо

    FIO

    Строка

    50

    Телефон для связи

    Tel

    Строка

    25

    Расчётный счёт

    Schet

    Действительное число

    ИНН

    Inn

    Действительное число

    БИК

    Bik

    Действительное число

    КПП

    Kpp

    Действительное число

    Таблица 3.12 – Структура таблицы «Списания»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Номер записи

    N

    Счетчик

    Код товара

    Id_tov

    Длинное целое число

    Дата списания товара

    Date

    Дата

    Номер акта на списание

    N_doc

    Строка

    10

    Количество списанного товара

    Kolvo

    Действительное число

    Код сотрудника, списавшего товар

    Id_sotrud

    Длинное целое число

    Код причины списания товара

    Id_reason

    Длинное целое число

    Таблица 3.13 – Структура таблицы «Причины списания товара»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Код причины списания товара

    Id_reason

    Счетчик

    Причина списания товара

    Reason

    Строка

    150

    Таблица 3.14 – Структура таблицы «Инвентаризация»

    Наименование поля

    Обозначение

    Тип данных

    Размер

    Номер записи

    N

    Счетчик

    Дата

    Date

    Дата

    Код товара

    Id_tov

    Длинное целое число

    Количество товара

    Kolvo

    Действительное число

    Поле для примечаний

    Note

    Строка

    200

    3.2 Логическая модель взаимосвязи таблиц базы данных системы

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


    Рисунок 3.1 - Логическая модель информационной системы

    3.3 Разработка программного обеспечения на примере дипломная работа модель системы

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

    На рисунке 4.2 введены следующие обозначения:

    Т1 - справочная таблица «Товары»;

    Т2 - справочная таблица «Наименования товаров»;

    Т3 - справочная таблица «Группы товаров»;

    Т4 - справочная таблица «Сотрудники»;

    Т5 - справочная таблица «Должности»;

    Т6 - справочная таблица «Клиенты»;

    Т7 - таблица «Продажи »;

    Т8 - таблица «Поставки»;

    Т9 - таблица «Заказы»;

    Т10 - справочная таблица «Поставщики»;

    Т11 - справочная таблица «Банки»;

    Т12 - таблица «Списания»;

    Т13 - справочная таблица «Причины списания товаров»;

    Т14 - таблица «Инвентаризация».

    Входные документы Д1-Д4 описаны в таблице 2.4, выходные документы D1-D6 представлены в таблице 2.3.

    Рисунок 3.2 – Схема информационной модели системы


    3.4 Описание алгоритмов и программ

    3.4.1 Описание алгоритма программного модуля расчёт гарантийного запаса товаров

    НАЧАТЬ алгоритм программного модуля расчёта гарантийного запаса товаров

    ОТОБРАЗИТЬ текущую дату

    ОРГАНИЗОВАТЬ меню выбора групп товаров

    ЕСЛИ не выбрана группа товаров

    ВЫВОД сообщения: «Выберите группу товаров для проведения

    анализа»

    ИНАЧЕ

    GZ.gr = код выбранной группы товаров

    ОТКРЫТЬ файл Prodagi

    ОТКРЫТЬ файл Postavshiki

    ОТКРЫТЬ файл Report_Remainder

    ОТКРЫТЬ вспомогательную таблицу GZ

    УДАЛИТЬ устаревшую информацию

    ОТКРЫТЬ файл Tovary

    УСТАНОВИТЬ фильтр с условием: Tovary.group = GZ.gr

    ЕСЛИ разработка программного обеспечения на примере дипломная работа файла

    ВЫВОД сообщения: «В справочнике Товары отсутствует информация по товарам группы < GZ.gr >»

    АВАРИЙНЫЙ_ВЫХОД

    К_Е

    ЦИКЛ пока не конец файла Tovary

    ПЕРЕЙТИ в рабочую область файла Prodagi

    УСТАНОВИТЬ фильтр с условием:

    Рисунок 3.3 – Алгоритм расчёт гарантийного запаса товаров

    Prodagi.id_tov = коду текущего товара

    && Prodagi.date <= dr && Prodagi.date >= dr-dt

    S = 0

    ЦИКЛ пока не конец файла Prodagi

    S = S + Prodagi.kolvo

    К_Ц

    PDN = S/dt

    ПЕРЕЙТИ в рабочую область файла Postavshiki

    УСТАНОВИТЬ фильтр с условием:

    Postavhiki.id_post = код поставщика текущего товара

    FGZ = (Post.tpost+ Post.zpost)* PDN – PDN* Post.tpost

    ПЕРЕЙТИ в рабочую область файла GZ

    ДОБАВИТЬ запись в таблицу GZ

    GZ.id_tov = коду текущего товара

    GZ.kolvo = S

    ОТМЕНИТЬ фильтр

    ОТМЕНИТЬ фильтр

    К_Ц // с переходом на следующую запись

    ПЕРЕЙТИ в рабочую область файла Report_Remainder

    ЕСЛИ Report_Remainder.kolvo <= GZ.kolvo

    ВЫВОД сообщения: «Для товара < GZ.gr > необходимо пополнить запас. Запустить формирование заказа?»

    ЕСЛИ выбран пункт меню да

    ЗАПУСТИТЬ алгоритм формирования заказа

    К_Е

    К_Е

    ЗАКРЫТЬ файл Tovari

    ЗАКРЫТЬ файл Report_Remainder

    ЗАКРЫТЬ файл Prodagi

    ПЕРЕЙТИ в рабочую область файла GZ

    УПОРЯДОЧИТЬ записи в порядке убывания поля GZ.kolvo

    ЗАКРЫТЬ файл GZ

    К_Е

    К_Е

    ВЫВОД файла АВС

    ЗАКРЫТЬ файл АВС

    КОНЕЦ_АЛГОРИТМА

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

    НАЧАТЬ алгоритм программного модуля формирование оптимального размера заказа

    ОТОБРАЗИТЬ текущую дату

    ОРГАНИЗОВАТЬ меню выбора планового периода

    ОРГАНИЗОВАТЬ меню выбора разработка программного обеспечения на примере дипломная работа товаров для пополнения запасов

    ЕСЛИ не разработка программного обеспечения на примере дипломная работа группа товаров

    ВЫВОД сообщения: «Выберите группу товаров для проведения анализа»

    ИНАЧЕ

    ORZ.gr = код выбранной группы товаров

    ОТКРЫТЬ файл Prodagi

    ОТКРЫТЬ файл Zakazi

    ОТКРЫТЬ вспомогательную таблицу ORZ

    УДАЛИТЬ устаревшую информацию

    ОТКРЫТЬ файл Tovary

    УСТАНОВИТЬ фильтр с условием: Tovary.group = ORZ.gr

    ЕСЛИ конец файла

    ВЫВОД сообщения: «В справочнике Товары отсутствует информация по товарам группы < ORZ.gr >»

    АВАРИЙНЫЙ_ВЫХОД

    К_Е

    ЦИКЛ пока не конец файла Tovary

    ПЕРЕЙТИ в рабочую область файла Prodagi

    УСТАНОВИТЬ фильтр с условием:

    Prodagi.id_tov = коду текущего товара

    && Prodagi.date <= dr && Prodagi.date >= dr-dt

    S = 0

    ЦИКЛ пока не конец файла Prodagi

    S = S + Prodagi.kolvo

    К_Ц

    ПЕРЕЙТИ в рабочую область файла ORZ

    ДОБАВИТЬ запись в таблицу ORZ

    ORZ.id_tov = коду текущего товара

    ORZ.kolvo = S

    ОТМЕНИТЬ фильтр

    К_Ц // с переходом на следующую запись

    ПЕРЕЙТИ в рабочую область файла Tovari

    УСТАНОВИТЬ фильтр с условием:

    Tovari.id_tov = коду текущего товара

    Q=S*

    ДОБАВИТЬ запись в таблицу Zakazi

    Zakazi.id_tov = коду текущего товара

    Zakazi.date = dr

    Zakazi.id_post = коду текущего поставщика

    Zakazi.kolvo = Q

    Zakazi.zena = Q*C

    ОТМЕНИТЬ фильтр

    ЗАКРЫТЬ файл Tovari

    ЗАКРЫТЬ файл Prodagi

    К_Е

    К_Е

    ВЫВОД файла Zakazi

    ЗАКРЫТЬ файл Zakazi

    КОНЕЦ_АЛГОРИТМА

    3.4.3 Описание алгоритма программного модуля формирование отчета «Объем продаж»

    НАЧАТЬ алгоритм программного разработка программного обеспечения на примере дипломная работа формирования отчета «Объем продаж»

    ОРГАНИЗОВАТЬ ввод периода формирования отчета и установки фильтра

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

    dn = дата начала периода

    dk = дата конца периода

    ОТКРЫТЬ файл Prodagi

    ОТКРЫТЬ файл Report_Prodagi

    УДАЛИТЬ устаревшую информацию

    ОТКРЫТЬ файл Tovari

    УСТАНОВИТЬ фильтр с условием: Tovari.group = выбранной группе

    ЕСЛИ конец файла

    ВЫВОД сообщения: «В справочнике Товары отсутствует информация по товару из группы <выбранная группа разработка программного обеспечения на примере дипломная работа пока не конец файла Tovari

    ПЕРЕЙТИ в рабочую область файла Prodagi

    УСТАНОВИТЬ фильтр с условием: Prodagi.date >= dn && Prodagi.date <= dk

    && Prodagi.id_tov = коду текущего имени товара

    Vprod = 0

    ЦИКЛ пока не конец файла Sale

    Vprod = Vprod + Prodagi.kolvo

    К_Ц // с переходом на следующую запись

    ДОБАВИТЬ строку в таблицу Report_Sale

    Report_Prodagi.id_group = Tovari.id_group

    Report_Prodagi.id_tov = Tovari.id_tov

    Report_Prodagi.amount = Vprod

    ОТМЕНИТЬ разработка программного обеспечения на примере дипломная работа // с переходом на следующую запись

    ОТМЕНИТЬ фильтр

    ЗАКРЫТЬ файлы Report_Prodagi, Prodagi

    КОНЕЦ_АЛГОРИТМА

    3.4.4 Описание алгоритма программного модуля формирование отчета «Ведомость остатков»

    НАЧАТЬ алгоритм программного модуля формирования отчета «Ведомость остатков»

    ОРГАНИЗОВАТЬ ввод периода формирования отчета и установки фильтра по группам товаров

    dn = дата начала периода

    dk = дата конца периода

    ОТКРЫТЬ файлы Tovari, Prodagi, Spisaniya

    ОТКРЫТЬ файл Report_Remainder

    УДАЛИТЬ устаревшую информацию

    ОТКРЫТЬ файл Разработка программного обеспечения на примере дипломная работа установлен фильтр по группе товаров

    УСТАНОВИТЬ фильтр с условием: Tovari.group = выбранной группе

    К_Е

    ЕСЛИ конец файла

    ВЫВОД сообщения: «В справочнике Товары отсутствует информация по товару из группы <выбранная группа товаров»

    АВАРИЙНЫЙ_ВЫХОД

    К_Е

    ЦИКЛ пока не конец файла Tovari

    ПЕРЕЙТИ в рабочую область файла Prodagi

    УСТАНОВИТЬ фильтр с условием:

    Sale.date >= dn && Prodagi.date = dk &&

    Prodagi.id_tov = коду текущего имени товара

    Vprod = 0

    ЦИКЛ пока не конец файла Tovari

    Vprod = Vprod + Prodagi.kolvo

    К_Ц // с переходом на следующую запись

    ОТМЕНИТЬ фильтр

    ПЕРЕЙТИ в рабочую область файла Postavki

    УСТАНОВИТЬ фильтр с условием:

    Postavki.date = dn && Postavki.date = dk &&

    Postavki.id_tov = коду текущего имени товара

    ЦИКЛ пока не конец файла Postavki

    Vprod разработка программного обеспечения на примере дипломная работа Vprod - Postavki.kolvo

    К_Ц // с переходом на следующую запись

    ОТМЕНИТЬ фильтр

    ПЕРЕЙТИ в рабочую область файла Spisaniya

    УСТАНОВИТЬ фильтр с условием:

    Spisaniya.date = dn && Spisaniya.date = dk &&

    Spisaniya.id_tov = коду текущего имени товара

    ЦИКЛ пока не конец файла Spisaniya

    Vprod = Vprod - Spisaniya.kolvo

    К_Ц // с переходом на следующую запись

    ОТМЕНИТЬ фильтр

    ДОБАВИТЬ строку в таблицу Report_Prodagi

    Report_ Remainder.id_group = Tovari.id_group

    Report_ Remainder.id_tov = Tovari.id_tov

    Report_ Remainder.kolvo = Vprod

    К_Ц // с переходом на следующую запись

    ОТМЕНИТЬ фильтр

    ЗАКРЫТЬ файлы Report_Remainder, Tovari, Postavki, Дипломную работу по дыхательной системы у детей Описание алгоритма программного модуля формирование отчета «Списания товаров»

    НАЧАТЬ алгоритм программного модуля формирования отчета «Списания товаров»

    ОРГАНИЗОВАТЬ ввод периода формирования отчета и установки фильтра

    по группам товаров

    dn = дата начала периода

    dk = дата конца периода

    ОТКРЫТЬ файл Spisaniya

    ОТКРЫТЬ файл Report_ Spisaniya

    УДАЛИТЬ устаревшую информацию

    ОТКРЫТЬ файл Tovari

    ЕСЛИ установлен фильтр по группе товаров

    УСТАНОВИТЬ фильтр с условием: Tovari.group = выбранной группе

    К_Е

    ЕСЛИ конец файла

    ВЫВОД сообщения: «В справочнике Товары отсутствует информация по товару из группы <выбранная группа товаров>»

    АВАРИЙНЫЙ_ВЫХОД

    К_Е

    ЦИКЛ пока не конец файла Tovari

    ПЕРЕЙТИ в рабочую область файла Write_off

    УСТАНОВИТЬ фильтр с условием:

    Spisaniya.date >= разработка программного обеспечения на примере дипломная работа && Spisaniya.date <= dk &&

    Spisaniya.id_name = коду текущего имени товара

    Vprod = 0

    ЦИКЛ пока не конец файла Spisaniya

    Vprod = Vprod + Spisaniya.kolvo

    К_Ц // с переходом на следующую запись

    ДОБАВИТЬ строку в таблицу Report_Spisaniya

    Report_ Spisaniya.id_group = Tovari.id_group

    Report_ Spisaniya.id_tov = Tovari.id_tov

    Report_ Spisaniya.kolvo = Vprod

    ОТМЕНИТЬ фильтр

    К_Ц // с переходом на следующую запись

    ОТМЕНИТЬ фильтр

    ЗАКРЫТЬ файлы Report_ Spisaniya, Spisaniya

    КОНЕЦ_АЛГОРИТМА

    Продолжение Рисунка 3.7

    3.5 Контрольный пример

    При запуске программы активируется диалоговое окно, представленное на рисунке 3.8, позволяющее идентифицировать пользователя. Если такой пользователь существует, то далее следует запуск главное окно системы, иначе выводится сообщение о том, что доступ запрещен и окно для ввода логина и пароля активируется снова.

    Рисунок 3.8 – Экранная форма идентификации пользователя

    Диалог системы и пользователя организован на основе меню. Меню системы представлено на рисунке 3.9.

    Главное меню программы содержит пять основных разделов: разработка программного обеспечения на примере дипломная работа, «Правка», «Справочники», «Отчёты», дипломная работа анализ кадровой политики и управление персоналом. Рассмотрим подробнее каждый из них.

    В разделе «Документы» выделены следующие подразделы:

    - «Поступления»;

    - «Продажи»;

    - «Списания»;

    - «Инвентаризация».

    Эти подразделы предназначены для ввода документов «Приходная накладная», «Расходная накладная», «Акт на списание» и «Инвентаризационная ведомость».

    Рассмотрим их работу на примере подпункта меню «Расход».


    Рисунок 3.9 – Главное меню программы

    Окно работы программы разделено на 2 части (см. рисунок 3.10). Первая часть предназначена для добавления новых записей на основе документа расходная накладная. Она имеет три поля для выбора наименования товара, заказчика, сотрудника, ответственного за отгрузку товара из справочников «Наименования товаров», «Сотрудники», «Клиенты». Так же эта часть окна предоставляет выбор даты продажи товара, ввод номера документа и количества проданного товара. На данной форме имеется две кнопки управления: «Очистить форму» и «Добавить запись». При нажатии кнопки «Очистить форму» в форме разработка программного обеспечения на примере дипломная работа записи очищаются все выбранные записи. При нажатии кнопки «Добавить строку» в базу данных добавляется новая строка и в нее записываются выбранные значения из бланка добавления записи. В другой части окна мы имеем возможность просмотра внесённых изменений в таблицу базы данных «Продажи».


    3.10 - Экранная форма «Продажи»

    Рассмотрим раздел меню «Справочники». В этом разделе предоставляется

    доступ к справочникам базы данных. Раздел «Справочники» разделен на следующие подразделы:

    - «Товар»;

    - «Наименования товаров»;

    - «Группы товаров»;

    - «Сотрудники»;

    - «Должность»;

    - «Клиенты»;

    - «Поставщики»;

    - «Банки»;

    - «Причины списания».

    Подпункты пункта меню «Справочники» предназначены для просмотра и редактирования справочников базы данных. Для этого предусмотрено два поля (см. рисунок 3.11): первое – добавление данных в справочник, второе – просмотр справочника системы.


    Рисунок 3.11 – Экранная форма «Поставщики»

    В пункте дипломная работа на тему школьная столовая «Отчеты» представлены все отчеты системы. К ним относят:

    - «Бланк заказа»;

    - «Объем продаж»;

    - «Ведомость остатков»;

    - «Списания».

    При выборе пункта меню «Ведомость остатков» появляется окошко (см. рисунок 3.12), предлагающее выбрать группу товаров для вывода таблицы ведомости остатков. При нажатии кнопки «Отмена» управление программой переходит в главное меню. При нажатии кнопки «ОК» программа начинает формирование ведомости по введенным параметрам.

    Рисунок 3.12 – Экранная форма задания параметров на формирование «Ведомости остатков»


    Рисунок 3.13 – Экранная форма «Ведомость остатков»

    Результаты формирования «Ведомости остатков» представлены на рисунке 3.13. На этой экранной форме имеется кнопка управления «Изменить параметры расчета». При нажатии этой кнопки программа открывает диалог задания параметров для когда проверяют дипломную работу на плагиат отчёта «Ведомость остатков».

    В столбце optim_kolvo таблицы «Ведомость остатков» указывается оптимальное количество товаров, рассчитанное исходя из затрат на хранение данного товара на складе. Значение 1 в столбце garantzapas показывает, что количество товара на данный момент меньше либо равно величине гарантийного запаса. Это означает, что пользователь увидев значение 1 в столбце должен пополнить запасы данного товара.

    При выборе пункта меню «Бланк заказа» появляется окошко (см. рисунок 3.12), предлагающее ввести пользователю номер заказа и количество товаров в заказе, а также выбрать дату заказа, наименование товара, поставщика и сотрудника оформившего заказ для вывода таблицы заказы.


    Рисунок 3.12 – Экранная форма «Бланк заказа»

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

    Результаты формирования таблицы «Заказы» представлены на рисунке 3.13. На этой экранной форме имеется кнопка управления «Изменить параметры расчета». При нажатии этой кнопки программа открывает диалог задания параметров для формирования «Бланка заказа».

    Рисунок 3.13 – Экранная форма «Заказы»

    4. Организационно экономическое обоснование дипломного проекта

    4.1 Целесообразность разработки с экономической точки зрения

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

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

    4.2 SWOT-анализ разработки

    Название данного метода анализа представляет собой аббревиатуру английских слов Strength (сила), Weakness (слабость), Opportunities (возможности), Threats (угрозы).

    Сильные стороны:

    - низкая стоимость разработки;

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

    - обеспечение сопровождения.

    Слабые стороны:

    - взаимодействие с другим ПО, в том числе и бухгалтерских.

    Возможности:

    - получение некоторых сведений по сети;

    - расширение круга пользователей.

    Угрозы:

    - изменение методов ведения работы,

    - выход системы из строя.

    Таблица 4.1 –SWOT-матрица

    Сильные

    стороны

    Возможности

    Угрозы.

    Итого

    Получение некоторых сведений по сети

    Расширение круга пользователей

    Изменение методов ведения работы

    Выход системы из строя

    Низкая стоимость разработки

    0

    +1

    0

    0

    +1

    Многофункциональность

    +2

    0

    +1

    0

    +3

    Обеспечение сопровождения

    +2

    0

    +2

    +2

    +5

    Итого

    +4

    +3

    +3

    +2

    +12

    Слабые

    стороны

    Взаимодействие с другим ПО

    -

    -

    0

    -

    -3

    Покупка пакета 1С

    0

    0

    0

    0

    0

    Итого

    -1

    -1

    0

    -1

    -3

    Общий итог

    +3

    +2

    +3

    +1

    +9

    Проанализировав полученную SWOT-матрицу, можно сделать литература для дипломных работ по психологии выводы:

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

    · Все выделенные слабые стороны разработки являются очень опасными. И, тем не менее, при правильном подходе они – разрешимы.

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

    · Наиболее опасной угрозой представляется изменение методов ведения работы, но при сложившихся условиях это не столь существенная угроза. Эта угроза представляется маловероятной вследствие налаженной работа с кадровым резервом дипломная отдела.

    4.3 Калькуляция себестоимости научно-технической продукции

    Таблица 4.2 – Материалы

    Наименование материальных затрат

    Ед. изм.

    Кол-во

    Цена без НДС с учетом комиссионных вознаграждений, таможенных пошлин и транспортных затрат

    Сумма

    USB – Flash носитель

    шт.

    1

    1000

    1000

    Бумага писчая ZOOM, пачка 500 листов

    шт.

    1

    270

    250

    Картридж для принтера Epson

    шт.

    1

    200

    200

    Канцтовары

    шт.

    5

    15

    70

    Итого:

    1625

    Таблица 4.3 –Оценка трудоемкости разработки

    Наименование этапа

    Трудоемкость этапа, часы

    1

    Анализ задания и знакомство с темой

    12

    2

    Изучение топологии сети и подбор литературы

    22

    3

    Изучение литературы

    60

    4

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

    40

    5

    Проектирование

    120

    6

    Отладка

    90

    7

    Составление и согласование проекта пакета служебных инструкций

    30

    Итого

    374

    Следовательно, всего на разработку затрачено 374 часа или 49 рабочих дней при восьмичасовом рабочем дне.

    3. Затраты на оплату труда работников, непосредственно занятых созданием научно-технической продукции

    Разработка выполнялась инженером-программистом в течение 46 рабочих дней при восьмичасовом рабочем дне. Месячный фонд времени работы инженера-программиста 160 часов, среднемесячная заработная плата 9000 руб.

    Основная заработная плата разработчика составила

    руб.

    Дополнительная заработная плата составляет 20%

    Здоп= 0,2*Зосн= 0,2*16247,37 = 2929,47 руб.

    Затраты на оплату разработка программного обеспечения на примере дипломная работа с учетом поясного коэффициента (25%)

    ЗТР= 1,25*(Зосн+Здоп)= 1,25*(16247,37+2929,47) = 21221,05 руб.

    4.4 Отчисления на социальные нужды

    Единый социальный налог.

    а) отчисления в Фонд Социального страхования(20% от затрат на оплату труда) 0,2*21221,05 = 4244,21 руб.;

    б) отчисления в Пенсионный фонд (2,9% от затрат на оплату труда) 0,029*21221,05 = 615,4 руб.;

    в) отчисления в Федеральный Фонд обязательного медицинского страхования (1,1% от затрат на оплату труда)

    0,011*21221,05 =233,44 руб.;

    Итого единый социальный налог 5517,47 руб.

    5. Прочие прямые расходы.

    Стоимость проезда составила 740 руб.

    6. Накладные расходы составляют 80% от затрат на оплату труда

    0,80*21221,05 = 16976,84 руб.

    Форма 1-пн

    Кафедра АСУ

    Калькуляция составлена

    "20" разработка программного обеспечения на примере дипломная работа 200 7 г.

    КАЛЬКУЛЯЦИЯ

    плановой себестоимости

    Автоматизированного рабочего места менеджера логистического отдела

    Основание для проведения работ (договор, заказ) ___заказ_______

    Заказчик: ЗАО Аптека Холдинг »

    Срок выполнения работы: начало 1 марта 2007 г._________________

    окончание 31 мая 2007г._______________

    Наименование статей затрат

    Сумма

    1

    Материалы

    1625,00

    2

    Спецоборудование для научных (экспериментальных) работ

    0,00

    3

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

    23721,00

    4

    Отчисления на социальные нужды

    6152,00

    5

    Прочие прямые расходы

    840,00

    6

    Накладные расходы

    16976,00

    7

    Итого:

    47259,00

    8

    Затраты по работам, выполняемым сторонними организациями и предприятиями

    0,00

    9

    Всего себестоимость

    47259,00

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

    Таким образом, назначив оптовую цену в 30000 руб. и реализовав 3 экземпляров программного обеспечения, мы получим следующую валовую прибыль

    30000 * 3 – 47259,00 = 43852,0 руб.

    Налог на прибыль (24%) составит

    0,24 * 43852,2 = 10524,53 руб.

    Ожидаемая разработка программного обеспечения на примере дипломная работа проекта

    .

    Отпускная цена одного экземпляра программы сестринский уход при мочекаменной болезни дипломная работа (с учетом НДС 18%)

    30000 * 1,18 = 35200 руб.

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

    5. Раздел «Охрана труда»

    5.1 Требования безопасности к хранению медикаментов на аптечных складах

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

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

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

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

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

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

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

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

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

    - Склад может размещаться в отдельно стоящем дипломная работа прибыль предприятия и ее распределение здании, здании производственного назначения или в нежилых помещениях жилых домов.

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

    При размещении склада в здании медицинского или аптечного назначения административно-бытовые помещения могут быть общими.

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

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

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

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

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

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

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

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

    · зону приемки продукции;

    · зону для основного хранения лекарственных средств;

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

    · экспедиционную.

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

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

    - Предприятие оптовой торговли должно быть оснащено оборудованием инвентарем в соответствии с выполняемыми функциями:

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

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

    · средствами механизации для погрузочно-разгрузочных работ;

    · приборами для регистрации параметров воздуха (термометрами, гигрометрами или психрометрами);

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

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

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

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

    · расстояние до наружных стен не менее 0,6 - 0,7 м;

    · расстояние до потолка не менее 0,5 м;

    · расстояние от разработка программного обеспечения на примере дипломная работа не менее 0,25 м;

    · проходы между стеллажами не менее 0,75 м;

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

    Организация хранения лекарственных средств:

    - Все товары на складе должны размещаться на стеллажах или на подтоварниках (поддонах) высотой не ниже 14,5 см. Не допускается размещение товара на полу без поддона. Каждое наименование и каждая серия лекарственных средств должны храниться на разработка программного обеспечения на примере дипломная работа поддонах. Поддоны могут располагаться на полу в один ряд или на стеллажах в несколько ярусов, в зависимости от высоты стеллажа. Не допускается размещение поддонов с лекарственными средствами друг на друга без стеллажей.

    Источник: https://domashke.net/referati/referaty-po-informatike/diplomnaya-rabota-razrabotka-programmnogo-obespecheniya-podderzhki-processov-ucheta-hraneniya-tovarov-na-sklade

    Основные направления деятельности компании ООО "Кварта": стратегический анализ, описание бизнес-процессов. Анализ факторов, воздействующих на достижение стратегических целей. Реорганизация структуры как важный шаг разработка программного обеспечения на примере дипломная работа совершенствованию деятельности компании

  • 1. Моделирование и планирование бизнес-процессов

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

    лабораторная работа, добавлен 21.07.2015

  • 2. Бизнес-процесс: понятие, структура, управление

    Процессный подход к управлению. Инструменты повышения эффективности бизнеса. Описание бизнес-процессов. Схема окружения бизнес-процесса. Детальное моделирование бизнес-процессов. Проведение глубокого предпроектного обследования деятельности компании.

    контрольная работа, добавлен 15.09.2014

  • 3. Разработка бизнес-процессов в ЗАО "Ясень" с применением технологии управления "1С:Молокозавод"

    Понятие бизнес-моделирования. Анализ финансово-хозяйственной деятельности компании ЗАО "Ясень"; разработка бизнес-процессов производства, их оптимизация и повышение эффективности работы предприятия с внедрением программного продукта "1С:Молокозавод".

    дипломная работа, добавлен 15.09.2012

  • 4. Реинжиниринг бизнес-процесса деятельности отдела контроля качества компании Destiny Development

    Проектирование совокупности взаимосвязанных бизнес-процессов предприятия как трудоемкий процесс по их моделированию. Модели прямого и обратного реинжиниринга в рамках стандарта моделирования бизнес-процессов IDEF0 на примере компании Destiny Development.

    курсовая работа, добавлен 22.04.2014

  • 5. Организация бизнес-процессов в ООО "Магазин Программного обеспечения"

    Управление бизнес-процессами как часть темы дипломных работ по изобразительной деятельности в доу компании. Автоматизация бизнес-процесса посредством внесения дополнительных документов в информационную систему 1С: Предприятие, используемую для учета коммерческой деятельности по распределению товаров.

    курсовая работа, добавлен 06.09.2015

  • 6. Анализ компании и формирование стратегии на примере ОАО "Аэрофлот"

    Исследование политики стратегического развития компании "Аэрофлот". Характеристика организации, анализ макро- микроокружения и внутренней среды. Правоотношений по социальному обеспечению дипломная работа стратегических групп, SWOT-анализ, цепочка ценностей М. Дипломная работа мероприятия по повышению качества продукции. Описание миссии и целей компании.

    курсовая работа, добавлен 18.04.2014

  • 7. Описание и моделирование бизнес-процессов ОАО "Урал"

    Определение процессного подхода к управлению организацией. Моделирование бизнес-процессов; объекты и связи в IDEF0, преимущества и недостатки их использования. Процессно-организационная бизнес-модель компании ОАО "Урал"; паспорт процесса "Продажа".

    курсовая работа, добавлен 03.05.2014

  • 8. Анализ деятельности ООО "Астор"

    Повышение конкурентоспособности компании за счет предоставления высококачественных услуг, ориентированных на клиента, - миссия компаний ООО "Астор". Цели компании, показатели их достижения. Анализ бизнес-процессов организации, характеристика работ.

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

  • 9. Практическое исследование бизнес-процессов туристской компании ООО "Охота!"

    Рассмотрение сущности понятия бизнес-процессов, определение их места и роли на рынке. Описание систематизированных подходов к анализу бизнес-процессов. Разработка практических мер управления бизнесом в сфере социально-культурного сервиса и туризма.

    курсовая работа, добавлен 07.09.2015

  • 10. Разработка бизнес-процессов в организации (на примере ООО "Мир стекла")

    Теоретические на тему органы предварительного следствия бизнес-моделирования. Анализ финансового положения и эффективности деятельности организации; изучение ее процессов: управленческого, основного и вспомогательного. Внедрение программного продукта для автоматизации процесса продаж.

    дипломная работа, добавлен 15.09.2012

  • Источник: http://allbest.ru/k-3c0a65625b3ad78a5d43b89521206c37.html

    Аннотация

     

    Родионов А.В. Материально-техническое обеспечение предприятия и пути его совершенствования, на примере ООО "ЧТПЗ". Челябинск: ЮУрГУ, ТЭ-523, 90 с., 16 ил., 21 табл., библиогр. разработка программного обеспечения на примере дипломная работа - 50 наим., 2 прил.

    Целью выпускной квалификационной работы является разработка мер по совершенствованию процессов снабжения в сфере материально-технического обеспечения ООО "ЧТПЗ".

    В выпускной квалификационной работе приведена основная характеристика предприятия, рассмотрено его финансовое состояние, изучена структура отдела снабжения ООО "ЧТПЗ" и рассмотрен процесс обеспечения предприятия материально-техническими ресурсами. Так же проведен анализ ликвидности бухгалтерского баланса разработка программного обеспечения на примере дипломная работа оборачиваемости запасов готовой продукции, сырья и материалов.

    В результате проведенной работы был предложен ряд рекомендаций, направленных на повышение эффективности материально-технического обеспечения ООО "ЧТПЗ". В частности, была разработана новая система снабжения сотрудников предприятия спецодеждой, процедура рейтинговой оценки поставщиков и методика оценки значимости материально-технических запасов, основанная на ABC-XYZ-анализе.

    снабжение сырье материал запас

    Оглавление

     

    Введение

    1. Теоретические основы организации материально-технического снабжения предприятия

    1.1 Понятие и сущность закупочной деятельности

    1.2 Цели и задачи закупочной деятельности

    1.3 Определение потребности в материально-технических ресурсах

    1.4 Выбор поставщиков материально-технических ресурсов

    1.5 Контроль и анализ закупок

    1.6 Зарубежный опыт материально-технического снабжения

    Выводы по разделу один

    2. Анализ Материально-технического обеспечения предприятия на примере ОАО "ЧТПЗ"

    2. Анализ Материально-технического обеспечения предприятия на примере ОАО "ЧТПЗ"

    2.1 Положение компании в отрасли

    2.2 Краткая организационно-экономическая характеристика предприятия

    2.3 Основные потребители и конкуренты ОАО "ЧТПЗ"

    2.4 Анализ разработка программного обеспечения на примере дипломная работа состояния предприятия

    2.5 Анализ материально-технического снабжения предприятия

    3. Разработка рекомендаций, направленных на повышение эффективности материально-технического обеспечения ОАО "ЧТПЗ"

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

    3.2 Рейтинговая оценка приоритетности запасов материально-технических ресурсов

    3.3 Совершенствование управления запасами спецодежды

    3.4 Внедрение рейтинговой оценки поставщиков

    Заключение

    Библиографический список

    Приложения

    Введение

     

    Осуществление закупок является начальным звеном развитие речи у детей с онр организаций, а от эффективности их функционирования зависят показатели всей производственно-хозяйственной деятельности.

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

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

    Помимо прочего, закупочная деятельность - одна из важнейших составляющих процесса управления запасами предприятия. Значение ее тем более велико, что снижение затрат всего лишь на 1 % приносит для предприятия в среднем разработка программного обеспечения на примере дипломная работа % дополнительной прибыли, что намного превышает аналогичные показатели для других частей бизнес-процесса. В связи с этим крайне важно оптимизировать закупочную деятельность, в частности, правильно определив размер заказа и момент его поступления. Как правило на практике для решения этой задачи пользуются формулой Вильсона. Но одним из предположений, в которых она выведена (и может быть использована), является предположение о неизменности закупочных цен. Однако на практике неизменность закупочных цен встречается лишь в узком временном инте�

    sИсточник: https://www.studsell.com/view/161845/

    Основные направления деятельности компании ООО "Кварта": стратегический анализ, описание бизнес-процессов. Анализ факторов, воздействующих на достижение стратегических целей. Реорганизация структуры как важный шаг к совершенствованию деятельности компании

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

    Размещено на http://www.allbest.ru/

    Курсоваяработа

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

    Содержание

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

    Введение

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

    1.1 Обоснование выбора организации

    1.2 Организационно-штатная структура

    1.3 Основные проблемы управления

    1.4 Постановка стратегических целей

    1.5 Анализ и выбор стратегии

    2.анализ и оптимизация бизнес-процессов

    2.1 Описание бизнес-процессов «как есть»

    2.2 Проблемы и задачи

    2.3 Анализ типовых вариантов процессов разработки

    2.4 Оптимизация процессов разработки и сопровождения

    3.Результаты и рекомендации

    3.1 Описание бизнес-процессов «как должно быть»

    3.2 Изменения в организационно-штатной структуре

    3.3 Регламентирование деятельности

    3.4 Перспективные направления автоматизации

    Заключение

    Список использованной литературы

    Приложение

    Образцы внутренних документов

    Приложение

    Регламент оперативного мониторинга информационной поддержки хода исполнения контрактных обязательств

    Приложение

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

    Приложение

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

    Приложение

    Типовая должностная инструкция специалиста-стажера Управления разработки прикладных систем

    Приложение

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

    Введение

    Данная аттестационная работа направлена на описание и оптимизацию бизнес-процессов компании-разработчика программного обеспечения (далее - ПО).

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

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

    Целью данной темы для дипломных работ по конфликтологии является выработка стандартов работы компании и оптимизация существующих бизнес-процессов. В работе необходимо выполнить следующие задачи:

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

    - описание текущего положения и штатной структуры компании;

    - описание существующих бизнес-процессов;

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

    - оптимизация штатной структуры компании;

    - анализ проблем и выработка решений по управленческим и кадровым проблемам компании;

    - создание образцов типовых документов;

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

    1.Стратегический анализ деятельности компании

    1.1 Обоснование выбора организации

    В качестве исследуемой организации выбрана ООО «Кварта».

    Основными направлениями деятельности компании являются:

    - разработка программного обеспечения (ПО);

    - внедрение и сопровождение программного обеспечения;

    - поставка аппаратного обеспечения;

    - техническая поддержка.

    При этом разработка ПО ведется в двух направлениях - ПО сферы бухгалтерского учета разрабатывается на одной платформе, а ПО остальных направлений - на другой (т.н. ИИС).

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

    Организационно-штатная структура компании еще больше усугубляет вышеуказанные проблемы.

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

    Описание организации приведено в Таблице 1.

    Таблица 1.Описание организации как объекта управления

    Параметр описания

    Характеристика

    Название, местонахождение

    ООО «Кварта», г. Москва

    Назначение

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

    Отраслевая принадлежность

    Отрасли третичного цикла

    Частная фирма

    Информационные технологии

    Правовая форма и вид собственности

    Коммерческое предприятие, общество с ограниченной ответственностью, частное

    Историческая справка

    Образовалась в 1993 году. Первый заказчик Управление делами Президента РФ Начало создания финансово-бухгалтерской системы, организация ЛВС. Постепенно в компании образовался ряд направлений примеры рецензий на от предприятия пример, которые впоследствии переросли в отдельные компании («Кварта-технологии», «Кварта-сети», «Кварта-консалтинг», Кадровое агентство «Кварта», «Сенсорные системы» и др.). Дипломная работа по легкой атлетике прыжки в высоту сама компания занялась разработкой интегрированных информационных систем управления предприятием (ИИС), а также комплексной автоматизацией организаций и предприятий. Основным направлением деятельности были выбраны федеральные органы законодательной исполнительной власти РФ. На данный момент заказчиками услуг компании являются Аппарат Правительства, Государственная Дума, Совет Федерации, Счётная палата, УД Президента РФ и большая часть Министерств, федеральных служб и агентств, включая подведомственные организации и загранучреждения, а также коммерческие организации различных форм черчень александра дипломная работа по обитателям болота 2 предоставляемых услуг постоянно растёт, появляются новые продукты. В планах компании расширить влияние в секторе муниципальных образований и продвижение в регионы. Также компания постепенно расширяет деятельность в секторе коммерческих предприятий.

    Организационная структура

    См. ниже (Модель «Цепочки ценностей»)

    Структура управления

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

    Параметр описания

    Характеристика

    Ресурсы

    Основной ресурс - сотрудники. Поощрение инициативных сотрудников, дружеская атмосфера в коллективе. Большое внимание уделяется обучению.

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

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

    Многолетний опыт работы и большое количество завершенных проектов, что позволяет участвовать и выигрывать конкурсы.

    Технические ресурсы: помещения, коммуникации (телефония, широкополосный доступ в Интернет), вычислительная техника, транспорт.

    Культура

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

    Ключевые факторы внешней среды

    Законодательство: Изменчивое законодательство, постоянные нововведения, часто не подкреплённые методическими рекомендациями, ограниченное время на реализацию изменений.

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

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

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

    Руководство

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

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

    Параметр описания

    Характеристика

    Модель «Цепочки ценностей»

    Процессы основной деятельности:

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

    Интеграция: полный комплекс услуг, начиная с этапа сбора информации и проектирования, до сдачи в эксплуатации функционирующих в соответствии с требованиями заказчика программно-аппаратных комплексов

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

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

    Предоставление услуг: также компания специализируется на предоставлении услуг по обслуживанию компаний, с уже работающей аппаратно-программной инфраструктурой, осуществляет, разрабатывает заказные продукты.

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

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

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

    Поддержка программно-аппаратной части компании

    Управление разработка программного обеспечения на примере дипломная работа (мотивация, обучение и пр.)

    Снабжение

    Внутренний финансово-бухгалтерский учёт

    Технологические исследования

    Делопроизводство

    1.2 Организационно-штатная структура

    Существующая штатная разработка программного обеспечения на примере дипломная работа организации приведена на Рисунке 1.

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

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

    Кадровая служба не существует в виде отдельного подразделения.

    Рисунок1.Существующаяштатнаяструктура.

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

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

    1.3 Основные проблемы управления

    В рассматриваемой организации существует ряд нижеперечисленных проблем управления.

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

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

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

    Наличие 2-х направлений разработки программных продуктов, часто имеющих схожий функционал. Отсутствие общей концепции, что приводит к дублированию, а часто и несовместимости собственных разработок. Также налицо неэффективное использование ресурсов. Это влечёт за собой дополнительный штат внедренческого персонала.

    Отсутствие планирования. Часто приводит к авральному выполнению проектов и нехватке сотрудников.

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

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

    1.4 Постановка стратегических целей

    В данный момент миссия и стратегия компании не сформулированы, поэтому попытаюсь их формулировать на основе собственного понимания и когда-то услышанных мыслей руководителя.

    Миссия

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

    Стратегический профиль

    Текущую стратегию я бы сформулировал следующим образом:

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

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

    Видение (стратегическое намерение)

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

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

    2. Что из себя представляет наш бизнес сейчас и каким он будет в будущем?

    В последнее время бизнес начал быстро развиваться. Количество заказов растет. Но четкого представления о планах и объемах работ нет практически не у кого. 80% времени персонал работает в авральном режиме. Рост внутри компании скорее носит экстенсивный характер (рост объема заказов - существенный рост штата), что не всегда оправдано. Приход новых клиентов часто происходит по принципу - мы слышали от тех-то, что есть такая компания, что у вас хорошие продукты разработка программного обеспечения на примере дипломная работа вас нашли. Маркетинговая политика отсутствует практически полностью.

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

    3. Кто является потребителями нашей продукции (услуг) и на какую группу покупателей организация будет ориентироваться в будущем?

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

    4. Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей?

    Следовать последним тенденциям в области разработки. Провести реинжиниринг в соответствии с требованиями ISO9001 и пройти сертификацию. Повысить качество продукта путем улучшения качества проектирования и ввода многоуровневой системы тестирования. Уделять больше внимания вопросам информационной безопасности. Создать консолидированную систему отчётности и базу знаний. Улучшить качество управления персоналом для повышения эффективности.

    Стратегические цели

    1. Сроки стратегического планирования.

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

    2. Генеральная цель.

    В течение 2-х лет отказаться от разработки двух линеек продуктов, перевести их на единую интегрированную платформу, сделать продукт современным и качественным, требующим малых трудозатрат на сопровождение.

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

    - Завершить реорганизацию структуры (создание новых структурных подразделений и распределение функций между ними)

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

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

    Повысить профессиональный уровень сотрудников

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

    - Внедрить систему аттестации сотрудников

    - Организовать процесс повышения профессиональной подготовки кадров

    - Проведение тематических семинаров

    Формализовать процессы.

    - Разработать должностные инструкции, ввести четкое разграничение полномочий

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

    - Организовать процесс документирования производимых работ

    - Стандартизировать процессы планирования и отчётности

    1.5 Анализ и выбор стратегии

    Результаты SWOT-анализа приведены в таблице 2 и таблице 3.

    Таблица2.Анализфакторов,воздействующихнадостижениестратегическихцелей

    Факторы

    Шифр

    Содержание

    Оценка

    Сильные стороны организации

    S1

    Сплоченный, высокопрофессиональный коллектив.

    7

    S2

    Хорошая технологическая база, финансовая независимость

    6

    S3

    Актуальные инновационные разработки, учитывающие специфику рынка

    8

    S4

    Отличная репутация и долгов время пребывания на рынке

    9

    Итого

    30

    Слабые стороны организации

    W1

    Две линейки однородных продуктов, одна из которых использует устаревшую платформу

    7

    W2

    Низкий уровень менеджмента организации, структура, не отвечающая текущим требованиям

    8

    W3

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

    6

    Итого

    21

    Возможности окружающей среды

    O1

    Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО

    7

    O2

    Наличие действующих контрактов, необходимых связей, владение необходимой информацией

    9

    O3

    Увеличение финансирования по программе «Электронная Россия», рост ИТ-рынка в целом

    8

    Итого

    24

    Угрозы окружающей среды

    T1

    Снижение финансирования госсектора, финансовые потрясения

    4

    T2

    Риск активизации текущих игроков рынка

    6

    T3

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

    8

    Итого

    18

    Таблица 3.Итоговая стратегическая матрица

    Сильные стороны организации

    Слабые стороны организации

    S1

    S2

    S3

    S4

    W1

    W2

    W3

    Возможности

    S3-O2 Увеличение объемов поставок решений заказчикам

    S4-O3 Рост количества клиентов

    S1-O3 Расширение линейки продуктов

    S3-O1 Практически монополия по ряду поставляемых задач

    S2-O2 Возможность работы в кредит

    S4-O1 Возможность получения дополнительных разрешений

    S2-O1 Возможность выпускать продукты с соотв. с самыми современными технологиями

    W1-O3 Использовать средства для модернизации линейки продуктов, вкладывать в новые технологии

    W3-O2 Возможность планирования работ заранее, оптимальное использование ресурсов

    W1-O1 Использование партнёрской поддержки для скорейшего освоения последних технологий

    W2-O3 Реорганизация системы управления, поиск профессиональных кадров

    O1

    O2

    O3

    Угрозы

    S1-T1 Возможность текучки кадров. Повышать заинтересованность, постоянный мониторинг.

    S2-T1 Не терять финансовую независимость, что позволит существовать в кризисные моменты достаточно продолжительное время, предоставлять возможность работы в кредит

    S3-T3 Постоянно отслеживать изменение технологий, заниматься перспективными разработками.

    S4-T2 Повышать авторитет, активно участвовать в конкурсах, отслеживать изменения стратегии у конкурентов

    S2-T2 выпускать новый продукт раньше, чем конкуренты

    W1-T3(Т1) Как можно скорее перейти на более совершенную платформу

    W3-T1(Т2) Развитие познавательной сферы старших дошкольников состояние рынка, тщательно планировать деятельность

    W2-T2 Привести структуру в соответствие с возникшей необходимостью, повышать квалификацию менеджеров

    T1

    T2

    T3

    T4

    Граф типовых стратегий организации приведен на рисунке 2.

    Выбор и обоснование стратегии

    В таблице 4 приведен выбор и оценка факторов, задействованных в трёх базовых стратегиях.

    Таблица4.Выбориоценкафакторов,задействованныхвтрёхбазовыхстратегиях

    (лидерствопоиздержкам)

    Факторы

    Оценка

    Реструктуризация

    Дифференциация

    Комбинированнаястратегия

    Удельный вес фактора

    Средне-взвешенная оценка фактора

    Удельный вес фактора

    Средне-взвешенная оценка фактора

    Удельный вес фактора

    Средне-взвешенная оценка фактора

    S1

    7

    0,1

    0,7

    0,1

    0,7

    0,1

    0,7

    S2

    6

    0,15

    0,9

    0,2

    1,2

    0,18

    1,08

    S3

    8

    0,1

    0,8

    0,25

    2

    0,17

    1,36

    S4

    9

    0,15

    1,35

    0,25

    2,25

    0,2

    1,8

    W1

    7

    0,15

    1,05

    0,05

    0,35

    0,1

    0,7

    W2

    8

    0,15

    1,3

    0,1

    0,8

    0,12

    0,96

    W3

    6

    0,2

    1,2

    0,05

    0,3

    0,13

    0,78

    Итого

    1

    7,3

    1

    7,6

    1

    7,38

    O1

    7

    0,15

    1,05

    0,2

    1,4

    0,17

    1,19

    O2

    9

    0,15

    1,35

    0,2

    1,8

    0,17

    1,53

    O3

    8

    0,15

    1,2

    0,25

    2

    0,2

    1,6

    T1

    4

    0,2

    0,8

    0,05

    0,2

    0,13

    0,52

    17T2

    6

    0,2

    1,2

    0,15

    0,9

    0,18

    1,08

    T3

    8

    0,15

    1,2

    0,15

    1,2

    0,15

    1,2

    Итого

    1

    6,8

    1

    7,5

    1

    7,12

    Посуммеоценок:

    По сумме оценок наилучшей стратегией является стратегия дифференциации.

    Пореальностизадействованныхфакторов:

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

    Выбраннаястратегия

    Возможные действия в рамках реализации стратегии:

    - Совершенствование и расширение линейки продуктов

    - Повышение профессионального уровня сотрудников

    - Повышение значимости планирования.

    - Агрессивная маркетинговая политика расширение партнёрских отношений.

    Возможные последствия реализации выбранной стратегии
    При грамотной реализации данной стратегии компания получит большое количество конкурентных штамп для альбомного листа а4 и по ряду продуктов и услуг станет недосягаема для конкурентов. Также произойдет рост компании и укрепление её имиджа на рынке информационных систем. Увеличатся доходы, и появится возможность выхода на новые рынки, а также усилится влияние на рынке информационных систем для федеральных органов власти.
    К недостаткам можно отнести следующее:
    Динамичный рост предложений продуктов и услуг, и как следствие, рост клиентской базы, не подкреплённые структурными разработка программного обеспечения на примере дипломная работа и достаточным количеством персонала, могут привести к авральному режиму разработка программного обеспечения на примере дипломная работа компании, и, как следствие, снижению качества продуктов и некоторому оттоку кадров. Расширения штата компании в достаточно короткий срок, что в свою очередь может быть связано с трудностями в обучении, адаптации сотрудников, а также существенно увеличит расходы.
    Надо очень серьёзно прорабатывать данные вопросы во избежание негативного влияния.

    Реализациясистемыпланов.Эффективностьизменений

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

    Таблица5.Определениенеобходимыхизменений

    Шифр

    Наименование

    Вес

    7S

    Реакция

    S1

    Сплоченный, высокопрофессиональный коллектив.

    0,8

    Shared Values

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

    S2

    Хорошая технологическая база, финансовая независимость

    0,7

    Skills

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

    S3

    Актуальные инновационные разработки, учитывающие специфику рынка

    1,4

    Skills

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

    S4

    Отличная репутация и долгов время пребывания на рынке

    1,7

    Strategy

    Skills

    W1

    Две линейки однородных продуктов, одна из которых использует устаревшую платформу

    0,7

    Strategy

    Skills

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

    W2

    Низкий уровень менеджмента организации, структура не отвечающая текущим требований

    1,2

    Systems

    Style

    Structure

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

    W3

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

    1

    Skills

    Strategy

    Разработка маркетинговой стратегии. Выработка стратегических планов и направлений развития компании на основе имеющихся знаний и возможностей.

    O1

    Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО

    1,4

    Skills

    Развивать партнёрские отношения с поставщиками. Лицензировать деятельность и обеспечивать наличие разрешений во всех требуемых направлениях.

    O2

    Наличие действующих контрактов, необходимых связей, владение необходимой информацией

    1,7

    Strategy

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

    O3

    Увеличение финансирования по программе «Электронная Россия», разработка программного обеспечения на примере дипломная работа ИТ рынка в целом

    1,6

    Strategy

    Развивать маркетинговую политику, активно участвовать в конкурсах, предлагать качественные, функциональные, опережающие конкурентов продукты

    T1

    Снижение финансирования госсектора, финансовые потрясения

    1,2

    Strategy

    Shared Values

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

    T2

    Риск активизации текущих игроков рынка

    0,7

    Strategy

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

    T3

    Зависимость от тенденций рынка в области платформ разработки

    1

    Skills

    Strategy

    Активно сотрудничать с поставщиками, развивать партнёрские отношения. Повышать профессиональный уровень сотрудников, заниматься инновационными разработками.

    Разработкамероприятий,программипланов

    Планирование

    1. Создание плана реорганизации.

    2. Планирование рабочего времени сотрудников.

    3. Создание маркетингового плана

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

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

    1. Реорганизация имеющихся департаментов и отделов, создание новых функциональных единиц, модернизация нового штатного расписания.

    2. Разработка всех технических регламентов и формализация процессов.

    3. Написание детальных должностных инструкций

    4. Детальное распределение полномочий и распределение проектов. Назначение ответственного за результат.

    Мотивация
    В таблице 6 приводятся показатели качества трудовой жизни.

    Таблица6.Показателикачестватрудовойжизни

    в данный момент

    Показатель

    Положение

    Справедливая заработная плата

    Рыночная оплата труда

    Присутствует (но ближе к нижней планке). Есть институт премирования по итогам года и завешенных проектов, носит субъективный характер.

    Обоснованная дифференциация оплаты труда

    В зависимости от должности

    Индивидуальная ответственность за результаты общего труда

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

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

    Фактически отсутствует

    Программа дополнительных выплат

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

    да, по базовой ставке оплаты труда

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

    да, в соответствии с КЗОТ

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

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

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

    на уровне «здравого смысла»: все используемое оборудование в работе соответствует международным стандартам безопасности, офисные площади планируются из рекомендованных разработка программного обеспечения на примере дипломная работа норм.

    Гарантия занятости

    Обеспечение непрерывности трудового стажа

    да, в соответствии с КЗОТ

    Уверенность работников в своем будущем

    Да, стабильная компания, 15 лет на рыке.

    Развитие способностей работников

    Обучение происходит стихийно или по необходимости.

    Социальная интеграция

    Социально-психологический микроклимат в организации

    Нейтральный. Много как позитивных, так и негативных моментов. Присутствует некая обособленность структурных единиц.

    Отношение руководства и подчиненных

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

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

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

    2. Управление собственностью: скорее исключает участие сотрудников в качестве партнеров по бизнесу.

    Исходя из перечисленных проблем в модели 7S и описания качества трудовой жизни - отсутствует формализованная система мотивации. Введен учёт по времени прихода на работу, но отсутствует фиксация отработанного времени разработка программного обеспечения на примере дипломная работа часто работают по 12 часов - но это не учитывается). Отсутствует система определения квалификации сотрудников. Определение вклада в общее дело носит субъективный характер иногда зависит от личных симпатий. Соответственно, необходимо разработать данную систему и утвердить ее на коллективном собрании сотрудников и учредителей.

    Контроль

    1. Внедрить в компании стандарты ISO9001, при необходимости разработать собственные стандарты качества. Ввести многоуровневые системы тестирования и контроля качества продуктов и услуг.

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

    3. Доработка внутренней ИС компании. Ведение отчетности, контроль выполнения и занятости, сравнительный анализ.

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

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

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

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

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

    2.Анализ и оптимизация бизнес-процессов

    2.1 Описание бизнес-процессов «как есть»

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

    Разработка

    Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

    - постановка задачи;

    - разработка;

    - тестирование;

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

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

    В стадии постановки задачи (например, написание ТЗ) участвуют как представители заказчика, так и сотрудники компании. При этом постановкой занимаются не профессиональные аналитики, а все, кто имеет хотя бы косвенное отношение к тематике: разработчики, внедренцы, документаторы.

    Диаграмма деятельности для стадии постановки задачи приведена на Рисунке 4.

    Рисунок4.Диаграммадеятельностидлястадиипостановкизадачи

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

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

    Процессы непосредственно разработки, а также последующего тестирования и документирования не формализованы. Чаще всего выбираются минимально необходимые свободные ресурсы, которым и передается ТЗ. Разработкой могут заниматься не только разработчики, но и специалисты по внедрению, чья дипломная работа обязательства из неосновательного обогащения позволяет выполнять какие-либо дополнительные задания по разработке. Процедура тестирования является необязательной, модульное тестирование осуществляется по желанию инициативе разработчика. Тестирование конечного продукта чаще всего проводится в процессе документирования, либо уже непосредственно при внедрении и обучении пользователей. Документирование также проводится по инициативе разработчика, на тему учетная политика для целей налогообложения, если условия контракта требуют предоставления комплекта документации, документированием может заниматься также документатор (при наличии свободных ресурсов) либо специалист по внедрению.

    Контроль над процессом является эпизодическим, осуществляется в основном уже непосредственно перед сдачей проекта. Официальная оценка результатов разработки продукта отсутствует.

    Внедрение и сопровождение

    Процесс внедрения, а также последующего сопровождения прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 5):

    - установка ПО;

    - обучение пользователей;

    - сбор замечаний;

    - устранение замечаний;

    - модернизация ПО.

    Рисунок5.Видыдеятельностипривнедренииисопровождении

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

    В таблице 7 приведены сводные данные по ролям и функциям.

    Таблица7.Своднаятаблицаролейифункций

    Функция

    Роль

    Итого

    разработчик

    специалист по внедрению

    документатор

    сотрудник тех. поддержки

    пользователь

    постановка задачи

    +

    +

    +

    +

    4

    разработка

    +

    +

    2

    тестирование

    +

    +

    +

    +

    4

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

    +

    +

    +

    3

    сбор замечаний

    +

    +

    +

    +

    4

    устранение замечаний

    +

    +

    2

    модернизация ПО

    +

    +

    2

    обучение

    +

    +

    +

    3

    установка ПО

    +

    +

    +

    3

    Всего

    8

    9

    3

    2

    5

    2.2 Проблемы разработка программного обеспечения на примере дипломная работа задачи

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

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

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

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

    - определение типа процесса для сопровождения существующих проектов;

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

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

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

    2.3 Анализ типовых вариантов процессов разработки

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

    На рисунке 6 приведен водопадный процесс разработки с указанием результатов на каждом этапе.

    Рисунок6.Водопадныйпроцессразработки

    Спиральныйпроцесс

    В случае спирального процесса последовательность «анализ - проектирование - реализация - тестирование» выполняется несколько раз. Основные причины использования спирального процесса обычно следующие:

    - необходимость предупреждения рисков;

    - необходимость предоставить заказчику частичную версию проекта до его завершения.

    Основной трудностью использования спирального процесса является поддержка актуальности документации.

    На рисунке 7 приведен спиральный процесс разработки.

    Рисунок7.Спиральныйпроцессразработки

    Инкрементальныйпроцесс

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

    Унифицированныйпроцесс

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

    На рисунке 8 приведен унифицированный процесс разработки.

    Рисунок8.Унифицированныйпроцессразработки

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

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

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

    2.4 Оптимизация процессов разработки и сопровождения

    При переходе к проектному управлению необходима реорганизация бизнес-процессов в соответствии с жизненным циклом реализации проектов. Жизненный цикл проекта - это комбинация процессов и подпроцессов, необходимых для создания (реализации) объекта или решения. Так, жизненный цикл проекта в стандарте PMI (Project Management Institute, США) состоит из следующих фаз:

    - начальная фаза (инициирование проекта);

    - разработка;

    - реализация;

    - завершение.

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

    Фазы могут обладать следующими характеристиками:

    - границы;

    - вход, выход;

    - длительность;

    - операции;

    - участники;

    - бюджеты.

    Проблематика управления проектами в современном менеджменте подробно разработана и доведена до стандартов. В стандартах проектного управления PMI жизненный цикл проекта разбивается на следующие типовые этапы:

    - процесс инициирования - принятие решения о начале выполнения проекта;

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

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

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

    - процесс управления - определение корректирующих воздействий, их согласование, утверждение и применение;

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

    Процессы управления проектами приведены на рисунке 9.

    Рисунок9.Процессыуправленияпроектами

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

    - границы;

    - документы на входе, документы на выходе;

    - временной регламент;

    - операции;

    - участники.

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

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

    - ведение систематизированного реестра проектов, позиционирование проектов по классификаторам реестра, задание типологии основных групп проектов;

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

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

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

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

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

    - бюджетирование проектов, включение бюджета проектов в основной бюджет компании.

    В рамках данной работы рассматриваются две группы процессов:

    - проекты по разработке новых прикладных систем;

    - проекты по сопровождению существующих систем.

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

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

    3.Результаты и рекомендации

    3.1 Описание бизнес-процессов «как должно быть

    Жизненный цикл нового проекта представлен на диаграмме деятельности (Рисунок 10).

    Рисунок10.Жизненныйциклновогопроекта

    СозданиеУставапроекта

    Устав проекта - официальный письменный документ, который формально признает и подтверждает факт существования проекта. Создание Устава проекта позволяет достичь следующих целей:


    Подобные документы

    • Анализ и оптимизация бизнес-процессов

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

      контрольная работа [1,5 M], добавлен 22.02.2017

    • Моделирование и планирование бизнес-процессов

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

      лабораторная работа [605,0 K], добавлен 21.07.2015

    • Бизнес-процесс: понятие, структура, управление

      Процессный подход к управлению. Инструменты повышения эффективности бизнеса. Описание бизнес-процессов. Схема окружения бизнес-процесса. Детальное моделирование бизнес-процессов. Проведение глубокого предпроектного обследования деятельности компании.

      контрольная работа [241,5 K], примеры раздаточных материалов на дипломную работу 15.09.2014

    • Разработка бизнес-процессов в ЗАО готовность детей к обучению в школе с применением технологии управления "1С:Молокозавод"

      Понятие бизнес-моделирования. Разработка программного обеспечения на примере дипломная работа финансово-хозяйственной деятельности расследование причинения вреда здоровью дипломная работа ЗАО "Ясень"; разработка бизнес-процессов производства, их оптимизация и повышение эффективности работы предприятия с внедрением программного продукта "1С:Молокозавод".

      дипломная работа [6,0 M], добавлен 15.09.2012

    • Реинжиниринг бизнес-процесса деятельности отдела контроля качества компании Destiny Development

      Проектирование совокупности взаимосвязанных бизнес-процессов предприятия как трудоемкий процесс разработка программного обеспечения на примере дипломная работа их моделированию. Модели прямого и обратного реинжиниринга в рамках стандарта моделирования бизнес-процессов IDEF0 на примере компании Destiny Development.

      курсовая работа [918,5 K], добавлен 22.04.2014

    • Организация бизнес-процессов в ООО "Магазин Программного обеспечения"

      Управление бизнес-процессами как часть стратегии компании. Автоматизация бизнес-процесса посредством внесения дополнительных документов в информационную систему 1С: Предприятие, используемую для учета коммерческой деятельности по распределению товаров.

      курсовая работа [26,8 K], добавлен 06.09.2015

    • Анализ компании и формирование стратегии на примере ОАО "Аэрофлот"

      Исследование политики стратегического развития компании "Аэрофлот". Характеристика организации, анализ макро- микроокружения и внутренней среды. Карта стратегических групп, SWOT-анализ, цепочка ценностей М. Портера. Описание миссии и целей компании.

      курсовая работа [423,9 K], добавлен 18.04.2014

    • Описание и моделирование бизнес-процессов ОАО "Урал"

      Определение процессного подхода к управлению организацией. Моделирование бизнес-процессов; объекты и связи в IDEF0, преимущества и недостатки их использования. Процессно-организационная бизнес-модель компании ОАО "Урал"; паспорт процесса "Продажа".

      курсовая работа [1,4 M], добавлен 03.05.2014

    • Практическое исследование бизнес-процессов туристской компании ООО "Охота!"

      Рассмотрение сущности понятия бизнес-процессов, определение их места и роли на рынке. Описание систематизированных подходов к анализу бизнес-процессов. Разработка практических мер управления бизнесом в сфере социально-культурного сервиса и туризма.

      курсовая работа [49,8 K], добавлен 07.09.2015

    • Анализ деятельности ООО "Астор"

      Повышение конкурентоспособности компании за счет предоставления высококачественных услуг, ориентированных на клиента, - миссия компаний ООО "Астор". Цели компании, показатели их достижения. Анализ бизнес-процессов организации, характеристика работ.

      отчет по практике [868,9 K], добавлен 21.12.2013

    Источник: https://knowledge.allbest.ru/management/3c0a65625b3ad78a5d43b89521206c37_0.html

    ВНИМАНИЕ! Документ в формате pdf

    СОДЕРЖАНИЕ

     

    Введение…………………………………………………………………&hellip.5

    1 Теоретические основы управления финансовыми ресурсами казенного учреждения………………………………………………………………&hellip.8

    1.1 Необходимость финансирования и состав источников казенного учреждения………………………………………………………………&hellip.8

    1.2 Правовые аспекты регулирования, формирования использования

    финансовых ресурсов…………………………………………………&hellip. 12

    2 Оценка финансового обеспечения ФКУ ИК-2…………………………23

    2.1 Организационно-экономическая характеристика ФКУ ИК-2……&hellip.23

    2.2 Анализ финансового обеспечения ФКУ ИК-2……………………&hellip.38

    3 Совершенствование финансового обеспечения ФКУ ИК-2………&hellip.46

    3.1 Выявление проблем в финансировании казенных учреждений&hellip.46

    3.2 Разработка мероприятий по совершенствованию финансового обеспечения ФКУ ИК-2……………………………………………………49

    Заключение…………………………………………………………………56

    Библиографический список……………………………………………&hellip.60

    Приложение А Баланс ФКУ ИК-2……………………………………&hellip.66

     

     

    Введение

     

    Бакалаврская работа содержит 65 с., 11 рисунков, 19 таблиц, 1 приложение, 52 источника.

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

    Объектом исследования послужило ФКУ ИК-2.

    Предметом исследования выступают финансовые ресурсы казенного учреждения.

    В процессе работы выявлена необходимость финансирования и состав источников казенного учреждения, раскрыты правовые аспекты регулирования, формирования использования финансовых ресурсов, дана организационно-экономическая характеристика ФКУ ИК-2, дана оценка финансового обеспечения учреждения.

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

    Для увеличения финансового обеспечения На тему коррекция девиантного поведения ИК-2 предлагается организация производства постельного белья в швейном цехе, продолжить работу по изготовлению малых архитектурных форм, освоить производство новых видов изделий: урн металлических уличных и скамеек металлических.

    Источник: http://examenna5.net/work/7118


    Аннотация


    Данный дипломный проект содержит 86 листов текста диплома, 18 рисунков, 4 таблицы, 5 приложений, 39 источников литературы.


    ИНФОРМАЦИОННАЯ СИСТЕМА, РАБОТА С ДАННЫМИ, ИНТЕФЕЙС, ТРЕБОВАНИЯ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА, МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ, ЛОГИЧЕСКАЯ МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, ФИЗИЧЕСКАЯ МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, БАЗА ДАННЫХ, ТЕСТИРОВАНИЕ, ФИЗИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ, ЛОГИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ.


    Темой дипломного проекта является «Информационная система учета призывников в администрации (на примере администрации с. Казинка)».


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


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



    СОДЕРЖАНИЕ


    Введение


    1. Разработка требований к программному обеспечению


    1.1 Анализ существующих решений по автоматизации предметной области


    1.3 Сбор требований


    1.4Спецификация требований


    1.5Аттестация требований


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


    2. Проектирование информационной системы


    2.1Архитектурное проектирование


    2.2Проектирование интерфейса информационной системы


    2.3Проектирование баз данных


    2.4Обоснование выбора платформы создания информационной системы


    2.5Проектирование модулей (объектно-ориентированные модели)


    3.Реализация и аттестация информационной системы


    3.1Реализация приложения


    3.2Взаимодействие приложения с источниками данных


    3.3Тестирование приложения


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


    4.Управление информационным проектом


    4.1Выбор жизненного цикла разработки ПО


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


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


    4.4Идентификация задач и действий


    4.5Оценка размера и возможности повторного использования


    4.6Оценка длительности и стоимости разработки проекта


    4.7Распределение ресурсов проекта


    4.8 Оценка экономической эффективности проекта


    ЗАКЛЮЧЕНИЕ


    Список литературы


    ПРИЛОЖЕНИЕ А - Спецификация требований к программному обеспечению


    ПРИЛОЖЕНИЕ Б – Прототиты пользовательского интерфейса


    ПРИЛОЖЕНИЕ В – Атрибуты управляющих таблиц возрастные особенности детей младшего школьного возраста презентация ИС


    ПРИЛОЖЕНИЕ Г - Выбор модели жизненного цикла


    ПРИЛОЖЕНИЕ Д – Диаграмма Гантта





    ВВЕДЕНИЕ


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


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


    Далее описывается значимость ИС для данной сферы деятельности. Основные решаемые задачи.


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


    Программа должна обеспечивать:


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


    ¾ получение выходных документов (структурированная информация содержащая вcе необходимые сведения о военнообязанных лицах);


    ¾ формирование отчетов (получение данных на бумажных носителях об отдельном лице, списке лиц).


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


    Для достижения вышеуказанной цели необходимо решить следующие задачи:


    ¾ провести анализ бизнес-процессов воинского учета;


    ¾ исследовать информационные потоки, возникающие в системе;


    ¾ разработать концептуальную и логическую модели данных;


    ¾ разработать программное обеспечение для АРМ воинского учета;


    ¾ провести оценку экономической эффективности информационной системы.


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


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


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


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




    1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ




    1.1 Анализ существующих решений по автоматизации предметной области


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


    Из существующих информационных систем можно выделить программную разработку "1С:Предприятие 8.0 Управление персоналом " компании 1С. предназначена для реализации кадровой политики компании по следующим направлениям: планирование потребностей в персонале, обеспечение бизнеса кадрами, кадровый учет, ведение регламентированного разработка программного обеспечения на примере дипломная работа [1].


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


    ¾ Ведение воинского учета в конфигурации организовано в соответствии со следующими нормативными документами:


    ¾ Федеральный закон от 26 февраля 1997 года № 31-ФЗ "О мобилизационной подготовке и мобилизации в Российской Федерации";


    ¾ Постановление Правительства РФ от 25 декабря 1998 года № 1541 "Об утверждении положения о воинском учете".


    В конфигурацию включены следующие отчеты, которые представляются организациями по запросам военкоматов либо разработка программного обеспечения на примере дипломная работа регулярной основе:


    ¾ Данные для постановки на учет в военкомате;


    ¾ Численность граждан запаса (формы №6 и 11/МУ);


    ¾ Список граждан, подлежащих постановке на воинский учет;


    ¾ Список принятых и уволенных военнообязанных;


    ¾ Список юношей 15-16 лет;


    ¾ Список для первоначальной постановки юношей на воинский учет;


    ¾ Список принятых и уволенных призывников


    Недостатками данной системы является:


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


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


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


    К еще одной информационной системе на которую стоит обратить внимание, можно отнести программный продукт ООО Научно-производственного центра разработка программного обеспечения на примере дипломная работа, Автоматизированная информационная система (АИС) Сельского Административного образования (САО) сокращенно (АИС САО) [2]. Система служит для автоматизации хозяйственной деятельности, похозяйственной книги, операций, выполняемых работниками муниципальных сельских администраций:


    ¾ ведение похозяйственного учета (в объеме книги похозяйственного учета)


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


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


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


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


    ¾ оформление и печать справок, выписок, постановлений,


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


    ¾ воинский учет с подготовкой пакета документов (повестки, акты, анкета).


    Система имеет многоуровневую структуру, объединяя 9 Автоматизированных Рабочих Мест (АРМ), в число которых входит АРМ «Данные о жителях»


    АРМ «Данные о жителях» позволяет реализовать следующие функции на основании реестра населения, формируемого системой:


    ¾ Подготовка и печать произвольных списков жителей. Как частный случай – подготовка списка призывников.


    ¾ Получать данные о собственности как отдельных персоналий, так и всей семьи (т.е. для членов хозяйства как для сельских подворий, так и для подворий МКД).


    ¾ Подготовка списков юбиляров.


    ¾ Учет и оформление документов по регистрации граждан.


    В том числе:


    ¾ Учет и оформление документов по воинскому учету.


    К недостатками данной системы можно отнести:


    ¾ Относительно высокая стоимость продукта;


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


    К последней информационной системе, которая будет рассмотрена в данном дипломном проекте, относится программный продукт ЗАО ИВЦ ИНСОФТ «Система Персонального Учета Населения» (СПУН).
    Система Персонального Учета Населения создана с целью формирования информационной базы для реализации процедур регистрации в рамках решаемых различными ведомствами задач Российской Федерации. В рамках данной системы имеется как будет на английском языке для регистрация граждан, имеющих статус военнообязанных. Система обладает необходимым набором средств для учета и оформление документов по воинскому учету[
    3].


    Недостатками данной информационной системы является:


    ¾ Высокая стоимость системы;


    ¾ Наличие высокоскоростного подключения в Интернет для режима постоянного доступа (on-line).


    1.2 Анализ предметной области


    Анализ предметной области необходимо проводить для:


    ¾ Определения функциональной направленности предприятия;


    ¾ Определения перечня структурных звеньев предприятия.


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


    Организационная структура сельской администрации представлена на рис. 1.1:




    Рисунок 1.1 – Организационная структура администрации


    Ниже перечислены функции темы для дипломных работ китайский администрации:


    ¾ бухгалтерия – начисление заработной платы, расчет платежами между организациями, ведение отчетности по налогам и сборам.


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


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


    ¾ отдел общего назначения – паспортный режим, прописка, выписка и т.д.


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


    Основными функциональными задачами отдела воинского учета являются:


    ¾ Постановка граждан на первоначальный воинский учет;


    ¾ Снятие с учета по причине смены места жительства;


    ¾ Снятие с учета по достижении возраста 50 лет;


    ¾ Ведение реестра граждан, подлежащих призыву;


    Моделирование бизнес процессов отдела воинского учета проведено с использованием CASE-средства RanionalRose [5,6]. Разработанная диаграмма бизнес-вариантов использования представлена на рис. 1.2. Она отображает перечисленные выше функциональные задачи отдела и показывает основные бизнес-актеров данного процесса.



    Рисунок 1.2 – Диаграмма бизнес-вариантов использования отдела воинского учета.


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





    1.3 Сбор требований


    Сбор требований – это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований [6].


    В данном проекте для сбора требований была выбрана методика «Интервьюирование» которая рассматривает следующие этапы:


    1. Разрабатываются вопросы


    2. Производится выбор опрашиваемых пользователей.


    3. Планируются контакты.


    4. Проводится интервью.


    5. Завершается встреча.


    6. Определяются последующие действия.


    А так же определены функциональные, системные требования и требования к интерфейсу системы:


    В процессе формирования требований принимали участие следующие лица:


    ¾ Глава администрации;


    ¾ Инспектор ВУС (Военно-учетного стола отдела воинского учета);


    ¾ Специалист первой категории администрации.


    На рисунке 1.3 представлена диаграмма вариантов использования ИС [5], представляющая процессы, происходящие в ИС отдела воинского учета.



    Рисунок 1.3 – Диаграмма вариантов использования ИС отдела воинского учета.


    1.4 Спецификация требований


    Определение разработка программного обеспечения на примере дипломная работа требований — ответственный этап программного проекта. Формат проекта должен соответствовать требованиям к ПО, собранным командой разработчиков или одним разработчиком, в противном случае эти требования не смогут быть поддержаны и представлены в программном продукте. Спецификация требований к ПО - SoftwareRequirementsSpecification(SRS) имеет ключевое значение для всего жизненного цикла разработки программного продукта. Это не только производный документ, в котором определены спецификации программного проекта, но и основной документ, применяемый с целью проведения аттестационных и приемочных испытаний. Аттестация — это оценка качества работы менеджеров проекта. Она определяет степень соответствия программного продукта установленным требованиям. Спецификация SRS выступает в роли некоего механизма фиксирования системных требований, которые используются в качестве критериев при аттестации [7].


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


    Снижаются временные затраты на разработку. В подготовке спецификации SRS задействованы различные лица в организации заказчика. Они тщательно исследуют все требования еще до того, как начнется непосредственная разработка проекта. Это снижает вероятность последующей повторной разработки проекта, кодирования и тестирования.


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


    Спецификация SRS становится основой для оценки стоимости и составления графика работ. Описание продукта — это реальный процесс необходимый для оценки стоимости проекта. В среде, где существует понятие формального предложения, SRS используют для утверждения оценки предложения или цены.


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


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


    В SRS документе рассматривается сам продукт, а не процесс разработки проекта, поэтому на ее основании можно производить расширение завершенного продукта.


    Спецификация требований к реализуемому программному обеспечению представлена в ПРИЛОЖЕНИИ А.


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




    1.5 Аттестация требований


    Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибки в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время разработки системы или после введения её в эксплуатацию [8-10].


    Для аттестации требований будет использован метод прототипирования. В этом случае конечным пользователям и заказчику дипломная работа на тему почты россии некий прототип системы.


    Прототип основного меню данного модуля представлен на рисунке 1.4.



    Рисунок 1.4 – Схема основного меню программы


    Интерфейс этого модуля должен обеспечить следующие дипломная работа обязательное страхование в рф пользователя:


    ¾ Создание новой записи о дипломные работы по основам безопасности жизнедеятельности с средней школе скачать бесплатно Загрузки данных из базы данных «Призывник» и действия с данными;


    ¾ Загрузки данных из базы данных «Запасник» и действия с данными;


    ¾ Загрузки данных из базы данных «Снятые с учета» и действия с данными;


    ¾ Загрузки данных из базы данных «Служащие в армии» и действия с данными;


    ¾ Загрузки данных из базы данных «Непригодные к службе» и действия с данными.


    Прототипы диалоговых окон программы представлены в Приложении Б.





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


    Существует две базовых методологии проектирования информационных систем: структурный и объектно-ориентированный анализ.


    Сущность структурного подхода к разработке информационной системы заключается в ее декомпозиции на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов [11,12].


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


    В объектном подходе акцент переносится на конкретные характеристики физической или абстрактной системы, являющейся предметом программного моделирования. Объекты обладают целостностью, которая не может быть нарушена. Таким образом, свойства, характеризующие объект и его поведение, остаются неизменными. Объект может только менять состояние, управляться или становиться в определенное отношение к другим объектам [13,14].


    Наиболее подходящей методологией проектирования ИС отдела воинского учета является объектно-ориентированная.



    Выводы


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




    2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ




    2.1 Архитектурное проектирование


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


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


    Архитектуры информационной системы требуется соблюдение следующих условий:


    ¾ соответствие с миссией организации;


    ¾ определенность в требованиях;


    ¾ направленность в разработке;


    ¾ возможность к адаптации;


    ¾ необходимость гибкости.


    Соблюдение всех этих условий позволяет разработать архитектуру информационной системы организации более совершенной и эффективной [15,17].


    Программные архитектуры, используемые в настоящее время:


    ¾ файл-серверная;


    ¾ клиент-серверная;


    ¾ многоуровневая.


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


    1. Многопользовательская работа с локальными таблицами на файл-сервере. В этом случае система Контур Стандарт и файл OLAP-приложения размещаются разработка программного обеспечения на примере дипломная работа клиентском компьютере, а таблицы исходных данных на файл-сервере. Это удобно, когда одни и те же исходные данные используются для выполнения различных видов анализа разными пользователями. Например, учетные данные, выгруженные из OLTP-системы в dbf-файл, анализируют бухгалтер и руководитель, причем каждый из них работает со своим аналитическим приложением.


    2. Многопользовательская работа с OLAP-приложениями исходными данными в виде локальных таблиц на файл-сервере. Тогда на компьютере пользователя устанавливается только Контур Стандарт с OLAP-машиной. Такая архитектура дипломные работы на тему субъективная сторона преступления работу группы пользователей (например, бухгалтерии) с одним и тем же аналитическим приложением. Доступ пользователей группы к файлу OLAP-приложения регламентируется средствами операционной системы [4].


    Архитектура "клиент-сервер" сегодня является доминирующей концепцией в создании распределенных сетевых приложений и предусматривает взаимодействие и как выровнять нумерацию в содержании дипломной работы данными между ними. Она предусматривает такие основные компоненты:


    ¾ набор серверов, предоставляющих информацию или другие услуги программам, которые обращаются к ним;


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


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


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



    Рисунок 2.1 – клиент-серверная архитектура.


    Серверы являются независимыми друг от друга. Клиенты также функционируют параллельно и независимо друг от правила признания лица инвалидом дипломная работа. Отсутствует жесткая привязка клиентов к серверам. Более чем типичной является ситуация, если один сервер одновременно обрабатывает запросы от разных клиентов; с другой стороны, клиент может обращаться то к одному серверу, то к другому. Клиенты должны знать о доступных серверах, но могут не иметь представления о существовании других клиентов. Общепринятым является соглашение, что клиенты и серверы - это, прежде всего программные модули. Чаще всего они находятся на разных компьютерах, но бывают ситуации, если обе программы - и клиентская, и серверная, физически размещаются на одной машине; в такой ситуации сервер часто называется локальным. Модель клиент-серверного взаимодействия определяется, прежде всего, распределением обязанностей между клиентом и сервером. Логически можно выделить три различные операции:


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


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


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


    Двухуровневая клиент-серверная архитектура предусматривает взаимодействие двух программных модулей - клиентского и серверного. В зависимости от того, как между ними распределяются приведенные выше функции, различают:


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


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


    Архитектура приложения, разделяющая пользовательские и прикладные сервисы и сервисы данных. Другое название - трехуровневая архитектура, однако термин «многоуровневая» корректнее, поскольку он предполагает, что при логическом проектировании может возникнуть более трех уровней сервисов. МНОГОУРОВНЕВАЯ АРХИТЕКТУРА ПРИЛОЖЕНИЯ (multi-tiered architecture), способ организации взаимодействия программ или компонентов программы. Как правило, Многоуровневая архитектура приложения используется в распределенных приложениях, компонеты которых выполняются на разных компьютерах. Частным случаем Многоуровневая архитектура приложения является архитектура клиент-сервер. В последнее время в информационных системах получила распространение архитектура, в которой распределенное приложение состоит из компонентов трех уровней:


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


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


    ¾ компонент, реализующий интерфейс с пользователем, исполняется на рабочей станции [4].


    В данном проекте выбрана клиент-серверная архитектура, т.к. информационная система будет использовать за сколько можно заказать дипломную работу базу данных на нескольких рабочих станциях. Сеть модели “клиент-сервер” уменьшает потребность Компьютеров-клиентов в оперативной памяти, поскольку вся работа с файлами выполняется на сервере. Серверы в клиент-серверных системах способны хранить большое количество данных. Благодаря этому на компьютерах-клиентах освобождается значительный объем дискового пространства для других приложений. Наконец, управление всей системой, включая контроль за ее безопасностью, становится намного проще, так как все файлы и данные централизованно размещаются на сервере или на небольшом числе серверов. Упрощается также резервное копирование.


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


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


    ¾ визуализации общей структуры исходного кода программной системы;


    ¾ спецификации исполнимого варианта программной системы;


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


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


    Диаграмма компонентов системы представлена на рисунке 2.2.



    Рисунок 2.2 – диаграмма компонентов информационной системы.


    Физическое представление программной системы не может быть полным, если отсутствует информация о отзыв руководителя на по психологии, на какой платформе и на каких вычислительных средствах она реализована. Второй формой физического представления является диаграмма развёртывания. Она применяется для представления общей конфигурации и топологии распределённой программной системы и разработка программного обеспечения на примере дипломная работа распределение компонентов по отдельным узлам системы. Диаграмма развёртывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе её исполнения. При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развёртывания не показываются.


    Диаграмма размещения представлена ниже на рисунке 2.3.



    Рисунок 2.3 – диаграмма размещения информационной системы.



    2.2 Проектирование интерфейса информационной системы


    Разработка пользовательского интерфейса включает те же основные этапы, что и разработка программного обеспечения:


    1. Определение типа интерфейса и общих требований к нему.


    2. Определение сценариев использования.


    3. Определение пользовательской модели интерфейса.


    4. Программирование и тестирование программных интерфейсов.


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


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


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


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


    Пользовательский интерфейс проектируемой информационной системы имеет следующую структуру: после запуска приложения открывается главная форма, которая содержит основное меню, состоящее из 3-ти пунктов меню: Файл, Данные, Помощь. Прототип пользовательского интерфейса ПРИЛОЖЕНИИ Б.




    2.3 Проектирование баз данных


    Основными целями проектирования базы данных являются:


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


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


    ¾ разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы — например, ко времени реакции системы [16].


    В основу проектирования БД должны быть положены представления конечных пользователей конкретной организации – концептуальные требования к системе. Именно конечный пользователь в своей работе принимает решения с учетом получаемой в результате доступа к базе данных информации. От оперативности и качества этой информации будет зависеть эффективность работы организации. Данные, помещаемые в базу данных, также предоставляет конечный пользователь.


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


    База данных должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам [14,16].


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


    Реализация логической модели начинается с определения концептуальной модели, определяющей основные сущности, сохраняемые в виде таблиц реляционной базы данных. ПРИЛОЖЕНИЕ В.


    На рисунке 2.4 пример концептуальной модели, на базе анализа сущностей



    Рисунок 2.4 – Концептуальная модель данных ИС.


    Доработка этой концептуальной модели с учетом атрибутов таблиц позволяет перейти непосредственно к логической модели БД.


    На рисунке 2.5 пример логической модели, на базе анализа сущностей



    Рисунок 2.5 – Логическая модель данных ИС.


    Физический уровень модели данных, напротив, зависит от конкретной системы управления базами данных, фактически являясь отображением системного каталога. В физическом уровне модели содержится информация о всех объектах базы данных. Поскольку стандартов на объекты базы данных не существует (например, нет стандарта на типы данных), физический уровень модели зависит от конкретной реализации системы управления базами данных. Следовательно, одному и тому же логическому уровню модели могут соответствовать несколько разных физических уровней различных моделей. Если на логическом уровне модели не имеет большого значения, какой конкретно тип данных у атрибута (хотя и поддерживаются абстрактные типы данных), то на физическом уровне модели важно описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах и т. д.


    Физической СУБД для ИС отдела воинского учета выбрана СУБД MicrosoftSQLServer 2005. Этот выбор осуществлен потому, что приложение будет функционировать на нескольких рабочих станциях используя базу данных одновременно по локальной сети. Также следует отметить, что СУБД MSSQLServer положительно зарекомендовала себя в процессе эксплуатации.


    СУБД MSSQLServer компании Microsoft начала разрабатываться в 1988 изначально предназначалась для платформы OS/2 [19,20]. Подземная разработка месторождений полезных ископаемых темы дипломных работ версии этого сервера баз данных предназначались для платформы WindowsNT и со временем были тесно интегрированы с этой операционной системой. Для других платформ версии этого сервера не выпускаются и не выпускались.


    Удобный пользовательский интерфейс утилит администрирования в сочетании с достаточно высокой производительностью и относительно невысокой стоимостью эксплуатации сделал эту серверную СУБД второй по популярности - после Oracle.


    Клиентские приложения для MicrosoftSQLServer и MSDE можно создавать как с помощью средств разработки Microsoft - VisualBasic, VisualC++, С#, Access и VisualFoxPro, так и с помощью средств разработки других производителей. Для этой цели имеются ODBC-драйвер и OLEDB-провайдер, а также содержащий их набор библиотек MicrosoftDataAccessComponents (MDAC), позволяющий использовать в средствах разработки объекты ActiveXDataObjects (ADO) - COM-объекты для доступа к данным. MDAC является составной частью WindowsXP, а для пользователей других Windows-платформ доступен отдельно на Web-сайте Microsoft.


    В отличие от Oracle, Microsoft не производит средств разработки, использующих тот же самый язык разработка программного обеспечения на примере дипломная работа, что и язык для создания кода триггеров и хранимых процедур, однако производит средства отладки серверного кода (например, SQLServerDebugger входит в состав VisualBasic и VisualC++).


    В настоящее время наиболее широко используемой является версия MSSQLServer 2005. В состав MicrosoftSQLServer 2005 входят простые утилиты администрирования (EnterpriseManager), сервисы преобразования данных (DataTransformationServices), облегчающие перенос данных в SQLServer из других типов СУБД, поддержка распределенных запросов и транзакций, OLAP-сервер и утилиты для создания хранилищ данных (в том числе данных из других серверных СУБД.


    ¾ масштабируемость и надежность. SQL Server 2005 обеспечивает практически неограниченный рост объемов данных за счет увеличения надежности и масштабируемости системы, используя все преимущества мультипроцессорной обработки данных. SQL Server 2005 Enterprise Edition обеспечивает параллельность обработки данных


    ¾ высокая скорость построения решений. SQL Server 2005 уменьшает время создания, развертывания и выхода на рынок современных приложений для задач бизнеса, электронной коммерции, использует встроенный отладчик T-SQL. Совершенствует и ускоряет процесс поиска данных, упрощает управление, позволяет использовать создаваемые пользователем функции в других приложениях [22,26].


    На рисунке 2.6 представлена физическая модель данных.



    Рисунок 2.6 – Разработка программного обеспечения на примере дипломная работа физической модели данных для ИС отдела воинского учета




    2.4 Обоснование выбора платформы создания информационной системы


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


    Чтобы средства разработки и технологии отвечали требованиям разработчиков, в корпорации Майкрософт была создана совершенно новая модель программирования для доступа к данным, основанная на .NETFramework. Построение на основе .NETFramework гарантирует единообразие доступа к данным: компоненты используют систему общих типов, общие шаблоны разработки и соглашения о пространствах дипломная работа по социальной работе казахстан [24,25].


    В .NETFramework поддерживается прямая и обратная совместимость. В контексте .NETFramework обратная совместимость означает, что любое приложение, созданное в .NETFramework разработка программного обеспечения на примере дипломная работа ранней версии, будет выполняться и в более поздней версии[29]. Прямая совместимость означает возможность выполнения приложения, созданного в более поздней версии .NETFrameworkSDKv 2.0, в .NETFramework более ранней версии.


    Классы ADO.NET были разработаны для поддержки возможностей новой модели программирования: интеграции на тему театрализованная игровая программа XML, единого представления данных с возможностью комбинирования данных из различных источников, а также средств оптимизации взаимодействия с базой данных, представленных в .NETFramework [29].


    Структура ADO.NET создана для разработка программного обеспечения на примере дипломная работа задач современной модели разработки приложений. В то же время модель программирования по возможности приближена к ADO, что упрощает переход разработка программного обеспечения на примере дипломная работа ADO к новой среде. ADO.NET является неотъемлемой частью .NETFramework, оставаясь понятной программистам ADO[28].


    .NET представляет собой совершенно новый способ создания распределенных настольных и встроенных приложений. Для типов .NET не нужны ни фабрики классов, ни поддержка IUnknown, ни регистрация в системном реестре. Эти основные элементы СОМ не скрыты – их просто больше нет.


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


    Платформа .NET является полностью независимой от используемых языков программирования. Можно использовать несколько .NET-совместимых языков программирования даже в рамках одного проекта.


    Основные возможности .NET следующие:


    ¾ Полные возможности взаимодействия с существующим кодом;


    ¾ Полное и абсолютное межъязыковое взаимодействие, межъязыковая обработка исключений и межъязыковая отладка;


    ¾ Общая среда выполнения для любых приложений .NET, вне зависимости от того, на каких языках они были созданы. Один из важных моментов при этом – то, что для всех языков используется один и тот же набор встроенных типов данных;


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


    ¾ Отсутствует сложность СОМ;


    ¾ Действительное упрощение процесса развертывания приложения.


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


    MicrosoftVisualStudio 2005 продолжает поддерживать технологии Microsoft .NETFramework уже в версии Microsoft .NETFrameworkSDKv2.0, которые предоставляют общеязыковую среду выполнения и унифицированные классы программирования. Также в VisualStudio включена библиотека MSDN, содержащая документацию по данным инструментам разработки.


    Платформа Microsoft.NET для отображения данных на компьютере конечного пользователя и его интерактивного взаимодействия с системой. предоставляет класс System.Windows.Forms.Form и большое разнообразие классов элементов управления, дочерних от класса Control. Функциональность уровня представления во многом определяется образец раздаточный материал к пример образец элементов управления, входящих в коллекцию Controls для конкретной формы [29].


    Уровень бизнес-логики отражает логику предметной области и реализует основные функции информационной системы. К таким функциям относятся вычисления на основе вводимых и хранимых данных, проверка элементов дипломная работа на тему блюда из птицы и обработка команд, поступающих от слоя представления, а также передача информации слою источника данных. Возможности, предоставляемые разработка программного обеспечения на примере дипломная работа Microsoft.NET, позволяют достаточно эффективно разработка программного обеспечения на примере дипломная работа вопросы корректности ввода пользователем данных и поэтому часть функций проверки элементов данных может быть решена на уровне представления.


    Уровень бизнес-логики получает на вход информацию от уровня представления, проводит необходимые проверки и вычисления, сохраняет в информацию базе данных и возвращает уровню представления определенные данные.


    Бизнес-логика описывается набором методов, реализующих бизнес-транзакцию. Для платформы Microsoft.NET это типовое решение сценарий транзакций использует прямой доступ к базе данных и базируется на использовании объектов классов DataCommand и DataReader технологии ADO.NET, а так же используя bindingSource, TableAdapter, DataSet. Класс, реализующий сценарий транзакций, обеспечивает прямой доступ к источнику данных и необходимую функциональность бизнес-логики. Для данного типового решения все разработка программного обеспечения на примере дипломная работа по реализации бизнес-логики возлагаются на методы сценария транзакций.


    Для разрабатываемой информационной системы выбрана платформа MicrosoftVisualStudio 2005. В качестве пример по строительству жилых домов реализации приложения выбран C# [23,26].



    2.5 Проектирование модулей (объектно-ориентированные модели)


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


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


    Уточнение модели анализа путём построения диаграмм взаимодействий и детализации диаграммы классов [33-35]. Внесение необходимых изменений и поправок в имеющуюся модель анализа, если необходимо.


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


    Определение с учётом ограничений налагаемые на архитектуру компонентов проектируемой системы, построение диаграммы компонентов.


    Модель проектирования представляется в разработка программного обеспечения на примере дипломная работа UML-диаграмм, схем, рисунков и описаний.



    Рисунок 2.7 - Диаграммы Состояний (Statechart) Информационной системы



    Рисунок 2.8 - Диаграммы Компонентов (Component) Информационной системы



    Выводы к разделу


    Во втором разделе рассмотрены архитектурное проектирование информационной системы, определяется пользовательский интерфейс системы. Проводится проектирование баз данных. Выбирается база данных которая будет удовлетворять требованиям разрабатываемой информационной системы. Определяются таблицы и тип хранимых данных в них. Определяется структура базы данных. Выбирается платформа для создания информационной системы. Для разрабатываемой информационной системы была выбрана платформа MicrosoftVisualStudio 2005. В качестве языка реализации приложения выбран C#.




    3. РЕАЛИЗАЦИЯ И АТТЕСТАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ




    3.1 Реализация приложения


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


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






    usingSystem.Data


    using System.Data.SqlClient;


    using System.Data.OleDb;




    Источник: http://2dip.su/дипломные_работы/11577/

    Курсовая работа

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

    Содержание

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

    Введение

    1.Стратегический как определить объект в дипломной работе деятельности компании

    1.1 Обоснование выбора организации

    1.2 Организационно-штатная структура

    1.3 Основные проблемы управления

    1.4 Постановка стратегических целей

    1.5 Анализ и выбор стратегии

    2.анализ и оптимизация бизнес-процессов

    2.1 Описание бизнес-процессов «как есть»

    2.2 Проблемы и задачи

    2.3 Анализ типовых вариантов процессов разработки

    2.4 Оптимизация процессов разработки и сопровождения

    3.Результаты и рекомендации

    3.1 Описание бизнес-процессов «как должно быть»

    3.2 Изменения в организационно-штатной структуре

    3.3 Регламентирование деятельности

    3.4 Перспективные направления автоматизации

    Заключение

    Список использованной литературы

    Приложение

    Образцы внутренних документов

    Приложение

    Регламент оперативного мониторинга информационной поддержки хода исполнения контрактных обязательств

    Приложение

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

    Приложение

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

    Приложение

    Типовая должностная инструкция специалиста-стажера Управления разработки прикладных систем

    Приложение

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


    Введение

    Данная аттестационная методы стимулирования продаж в торговле дипломная работа направлена на описание и оптимизацию бизнес-процессов компании-разработчика программного обеспечения (далее – ПО).

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

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

    Целью данной работы является выработка стандартов работы компании и оптимизация существующих бизнес-процессов. В работе необходимо выполнить следующие задачи:

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

    - описание текущего положения и штатной структуры компании;

    - описание существующих бизнес-процессов;

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

    - оптимизация штатной структуры компании;

    - анализ проблем и выработка решений по управленческим и кадровым проблемам компании;

    - создание образцов типовых документов;

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

    1.Стратегический анализ деятельности компании

    1.1 Обоснование выбора организации

    ВкачествеисследуемойорганизациивыбранаООО«Кварта».

    Основными направлениями деятельности компании являются:

    - разработка программного обеспечения (ПО);

    - внедрение и сопровождение программного обеспечения;

    - поставка аппаратного обеспечения;

    - техническая поддержка.

    При разработка программного обеспечения на примере дипломная работа разработка ПО ведется в двух направлениях – ПО сферы бухгалтерского учета разрабатывается на одной платформе, а ПО остальных направлений – на другой (т.н. ИИС).

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

    Организационно-штатная структура компании еще больше усугубляет вышеуказанные проблемы.

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

    Описание организации приведено в Таблице 1.


    Таблица 1.Описание организации как объекта управления

    Параметр описанияХарактеристика
    Название, местонахождениеООО «Кварта», г. Москва
    НазначениеОказание услуг автоматизации для федеральных и территориальных органов государственной власти, бюджетных учреждений, а также для малых и средних предприятий (разработчик и поставщик услуг по внедрению и сопровождению автоматизированных информационных систем (АИС), системная интеграция)
    Отраслевая принадлежность

    Отрасли третичного цикла

    Частная фирма

    Информационные технологии

    Правовая форма и вид собственностиКоммерческое предприятие, общество с ограниченной ответственностью, частное
    Историческая справка

    Образовалась в 1993 году. Первый заказчик Управление делами Президента РФ Начало создания финансово-бухгалтерской системы, организация ЛВС. Постепенно в компании образовался ряд направлений деятельности, акт о внедрении дипломной работе образец впоследствии переросли в отдельные компании («Кварта-технологии», «Кварта-сети», «Кварта-консалтинг», Кадровое агентство «Кварта», «Сенсорные системы» и др.). Непосредственно сама компания занялась разработкой интегрированных информационных систем управления предприятием (ИИС), а также комплексной автоматизацией организаций и предприятий. Основным направлением деятельности были выбраны федеральные органы законодательной исполнительной власти РФ. На данный момент заказчиками услуг компании являются Аппарат Правительства, Государственная Дума, Совет Федерации, Счётная палата, УД Президента РФ и большая часть Министерств, федеральных служб и агентств, включая подведомственные организации и загранучреждения, а также коммерческие организации различных форм собственности.

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

    Организационная структураСм. ниже (Модель «Цепочки ценностей»)
    Структура управленияВ данный момент компания использует вертикальную систему нарушение речи у детей с нарушением интеллекта от генерального директора к руководителям структурных подразделений (департаментов), часть из которых выполняет функции заместителей, далее к начальникам отделов и групп. Подразделения поделены по функциональному признаку. В последнее время в связи с большим количеством разнородных проектов, требующих специалистов разных направлений, постепенно вводится практика назначения руководителей проектов (как правило руководители отделов) и планируется серьёзная структурная реорганизация.
    Параметр описанияХарактеристика
    Ресурсы

    Основной ресурс – сотрудники. Поощрение инициативных сотрудников, дружеская атмосфера в коллективе. Большое внимание уделяется обучению.

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

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

    Многолетний опыт работы и большое количество завершенных проектов, что позволяет участвовать и выигрывать конкурсы.

    Технические ресурсы: помещения, коммуникации (телефония, широкополосный доступ в Интернет), вычислительная техника, транспорт.

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

    Законодательство: Изменчивое законодательство, постоянные нововведения, часто не подкреплённые методическими рекомендациями, ограниченное время на реализацию изменений.

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

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

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

    Руководство

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

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

    Параметр описанияХарактеристика
    Модель «Цепочки ценностей»

    Процессы основной деятельности:

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

    Интеграция: полный комплекс услуг, начиная с этапа сбора информации и проектирования, до сдачи в эксплуатации функционирующих в соответствии с требованиями заказчика программно-аппаратных комплексов

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

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

    Предоставление услуг: также компания специализируется на колеса и шины дипломная работа по автомобилям услуг по обслуживанию компаний, с уже работающей аппаратно-программной инфраструктурой, осуществляет, разрабатывает заказные продукты.

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

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

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

    Поддержка программно-аппаратной части компании

    Управление персоналом (мотивация, обучение разработка программного обеспечения на примере дипломная работа пр.)

    Снабжение

    Внутренний финансово-бухгалтерский учёт

    Технологические исследования

    Делопроизводство

    1.2 Организационно-штатная структура

    Существующая штатная структура организации приведена на Рисунке 1.

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

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

    Кадровая служба не существует в виде отдельного подразделения.

    Рисунок 1. Существующая штатная структура.


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

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

    1.3 Основные проблемы управления

    В рассматриваемой организации существует ряд нижеперечисленных проблем управления.

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

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

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

    Наличие 2-х направлений разработки программных продуктов, часто видео презентации для защиты дипломной работы схожий функционал. Отсутствие общей концепции, что приводит к дублированию, а часто и несовместимости собственных разработок. Также налицо неэффективное использование ресурсов. Это влечёт за собой дополнительный штат внедренческого персонала.

    Отсутствие планирования. Часто приводит к авральному выполнению проектов и нехватке сотрудников.

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

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

    1.4 Постановка стратегических целей

    В данный момент миссия и стратегия компании не сформулированы, поэтому попытаюсь их формулировать на основе собственного понимания и когда-то услышанных мыслей руководителя.

    Миссия

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

    Стратегический профиль

    Текущую стратегию я бы сформулировал следующим образом:

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

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

    Видение (стратегическое намерение)

    1. Какой мы хотим видеть свою организацию в будущем?

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

    2. Что из себя представляет наш бизнес сейчас и каким он будет в разработка программного обеспечения на примере дипломная работа последнее время бизнес начал быстро развиваться. Количество заказов растет. Но четкого представления о планах и объемах работ нет практически не у кого. 80% времени персонал работает в авральном режиме. Рост внутри компании скорее носит экстенсивный характер (рост объема заказов – существенный рост штата), что не всегда оправдано. Приход новых клиентов часто происходит по принципу - мы слышали от тех-то, что есть такая компания, что у вас хорошие продукты и вас нашли. Маркетинговая политика отсутствует практически полностью.

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

    3. Кто является потребителями нашей продукции (услуг) и на какую группу покупателей организация будет ориентироваться в будущем?

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

    4. Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей?

    Следовать последним тенденциям в области разработки. Провести реинжиниринг в соответствии тема дипломной работы по информатике в образовании требованиями ISO9001 и пройти сертификацию. Повысить качество продукта путем улучшения качества проектирования и ввода многоуровневой системы тестирования. Уделять дипломные работы по молодежной политике рф внимания вопросам информационной безопасности. Создать консолидированную систему отчётности и базу знаний. Улучшить качество управления персоналом для повышения эффективности.

    Стратегические цели

    1. Сроки стратегического планирования.

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

    2. Генеральная цель.

    В течение 2-х лет отказаться разработка программного обеспечения на примере дипломная работа разработки двух линеек продуктов, перевести их на единую интегрированную платформу, сделать продукт современным и качественным, требующим малых трудозатрат на сопровождение.

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

    - Завершить реорганизацию структуры (создание новых структурных подразделений и распределение функций между ними)

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

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

    Повысить профессиональный уровень сотрудников

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

    - Внедрить систему аттестации сотрудников

    - Организовать процесс повышения профессиональной подготовки кадров

    - Проведение тематических семинаров

    Формализовать процессы.

    - Разработать должностные инструкции, ввести четкое разграничение полномочий

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

    - Организовать процесс документирования производимых работ

    - Стандартизировать процессы планирования и отчётности

    1.5 Анализ и выбор стратегии

    Результаты SWOT-анализа приведены в таблице 2 и таблице 3.

    Таблица 2.Анализ факторов, воздействующих на достижение стратегических целей

    ФакторыШифрСодержаниеОценка
    Сильные стороны организацииS1Сплоченный, высокопрофессиональный дипломная работа на тему уголовная ответственность за разбой технологическая база, финансовая независимость6
    S3Актуальные инновационные разработки, учитывающие специфику рынка8
    S4Отличная репутация и долгов время пребывания на рынке9
    Итого30
    Слабые стороны организацииW1Две линейки однородных продуктов, одна из которых использует устаревшую платформу7
    W2Низкий уровень менеджмента организации, структура, не отвечающая текущим требованиям8
    W3Отсутствие маркетинговой политики и долгосрочного планирования6
    Итого21
    Возможности окружающей средыO1Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО7
    O2Наличие действующих контрактов, необходимых связей, владение необходимой информацией9
    O3Увеличение финансирования по программе «Электронная Россия», рост ИТ-рынка в целом8
    Итого24
    Угрозы окружающей средыT1Снижение финансирования госсектора, финансовые потрясения4
    T2Риск активизации текущих игроков рынка6
    T3Зависимость от тенденций рынка в области платформ разработки8
    Итого18

    Таблица 3.Итоговая стратегическая матрица

    Сильные стороны организацииСлабые стороны организации
    S1S2S3S4W1W2W3
    Возможности

    S3-O2 Увеличение объемов на тему учетная политика в организации решений заказчикам

    S4-O3 Рост количества клиентов

    S1-O3 Расширение линейки продуктов

    S3-O1 Практически монополия по ряду поставляемых задач

    S2-O2 Возможность работы в кредит

    S4-O1 Возможность получения дополнительных разрешений

    S2-O1 Возможность выпускать продукты с соотв. с самыми современными технологиями

    W1-O3 Использовать средства для модернизации линейки продуктов, вкладывать в новые технологии

    W3-O2 Возможность планирования работ заранее, оптимальное использование ресурсов

    W1-O1 Использование партнёрской поддержки для скорейшего освоения последних технологий

    W2-O3 Реорганизация системы управления, поиск профессиональных кадров

    O1
    O2
    O3
    Угрозы

    S1-T1 Возможность текучки кадров. Повышать заинтересованность, постоянный мониторинг.

    S2-T1 Не терять финансовую независимость, что позволит существовать в кризисные моменты достаточно продолжительное время, предоставлять возможность работы в кредит

    S3-T3 Постоянно отслеживать изменение технологий, заниматься перспективными разработками.

    S4-T2 Повышать авторитет, активно участвовать в конкурсах, отслеживать изменения стратегии у конкурентов

    S2-T2 выпускать новый продукт раньше, чем конкуренты

    W1-T3(Т1) Как можно скорее перейти на более совершенную платформу

    W3-T1(Т2) Отслеживать состояние рынка, тщательно планировать деятельность

    W2-T2 Привести структуру в соответствие с возникшей необходимостью, повышать квалификацию менеджеров

    T1
    T2
    T3
    T4

    Граф типовых стратегий организации приведен на рисунке 2.

    Рисунок 2. Граф типовых стратегий

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

    Таблица 4.Выбор и оценка факторов, задействованных в трёх базовых стратегиях

    ФакторыОценкаРеструктуризация (лидерство по издержкам)ДифференциацияКомбинированная стратегия
    Удельный вес фактораСредне-взвешенная оценка фактораУдельный вес фактораСредне-взвешенная методические вказивки по дисциплина оценка финансового состояния предприятий фактораУдельный вес фактораСредне-взвешенная оценка фактора
    S170,10,70,10,70,10,7
    S260,150,90,21,20,181,08
    S380,10,80,2520,171,36
    S490,151,350,252,250,21,8
    W170,151,050,050,350,10,7
    W280,151,30,10,80,120,96
    W360,21,20,050,30,130,78
    Итого17,317,617,38
    O170,151,050,21,40,171,19
    O290,151,350,21,80,171,53
    O380,151,20,2520,21,6
    T140,20,80,050,20,130,52
    17T260,21,20,150,90,181,08
    T380,151,20,151,20,151,2
    Итого16,817,517,12

    По сумме оценок:

    По сумме оценок наилучшей стратегией является стратегия дифференциации.

    По реальности задействованных факторов:

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

    Выбранная стратегия

    Возможные действия в рамках реализации стратегии:

    - Совершенствование и расширение линейки продуктов

    - Повышение профессионального уровня сотрудников

    - Повышение значимости планирования.

    - Агрессивная маркетинговая политика расширение партнёрских отношений.

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

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

    К недостаткам можно отнести следующее:

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

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

    Реализация системы планов. Эффективность изменений

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

    Таблица 5.Определение необходимых изменений

    ШифрНаименованиеВес7SРеакция
    S1Сплоченный, высокопрофессиональный коллектив.0,8Shared ValuesДержать уровень оплаты труда на рыночном уровне, предоставлять бонусы и гарантии. Разработать программы мотивации и повышения квалификации персонала, ввести аттестацию.
    S2Хорошая технологическая база, финансовая независимость0,7SkillsТехнологическая база должна соответствовать современному уровню, обновлять при необходимости, использовать имеющиеся возможности для привлечения перспективных клиентов (кредит…)
    S3Актуальные инновационные разработки, учитывающие специфику рынка1,4SkillsПоддерживать высокое качество продуктов, уделять больше внимания заказчикам. Донести до потенциальных заказчиков преимущества (маркетинговая программа), всегда быть в курсе последних изменений, выводить на рынок продукты раньше конкурентов.
    S4Отличная репутация и долгов время пребывания на рынке1,7

    Strategy

    Skills

    W1Две линейки однородных разработка программного обеспечения на примере дипломная работа, одна из которых использует устаревшую платформу0,7

    Strategy

    Skills

    Отказаться от разработки двух линеек продуктов, перевести их дипломная работа по уголовному праву республики беларусь единую интегрированную платформу, сделать продукт современным и качественным. Постоянно проводить инновационные исследования и создать непрерывный цикл периодических обновлений.
    W2Низкий уровень менеджмента организации, структура не отвечающая текущим требований1,2

    Systems

    Style

    Structure

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

    W3Отсутствие маркетинговой политики и рынок кваса и безалкогольных напитков в россии 2017 показатели и прогнозы планирования1

    Skills

    Strategy

    Разработка маркетинговой стратегии. Выработка стратегических планов и направлений развития компании на основе имеющихся знаний и возможностей.
    O1Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО1,4SkillsРазвивать партнёрские отношения с поставщиками. Лицензировать деятельность и обеспечивать наличие разрешений во всех требуемых направлениях.
    O2Наличие действующих контрактов, необходимых связей, владение необходимой информацией1,7

    Strategy

    Обеспечивать качественное выполнение контрактов с целью их физическая культура и спорт дипломная работа, расширения услуг и повышения репутации. Расширять связи с целью своевременного получения информации.
    O3Увеличение финансирования по программе «Электронная Россия», рост ИТ рынка в целом1,6

    Strategy

    Развивать маркетинговую политику, активно участвовать в конкурсах, предлагать качественные, функциональные, опережающие конкурентов продукты
    T1Снижение финансирования госсектора, финансовые потрясения1,2

    Strategy

    Shared Values

    Иметь резервные фонды и возможность предоставления услуг в кредит, широкий спектр продуктов и услуг. Поддерживать коллективный дух и корпоративные ценности.
    T2Риск активизации текущих игроков рынка0,7StrategyВести активный мониторинг рынка. Владеть информацией. Иметь широкую продуктовую линейку с сильными конкурентными преимуществами.
    T3Зависимость от тенденций рынка в области платформ разработки1

    Skills

    Strategy

    Активно сотрудничать с поставщиками, развивать партнёрские отношения. Повышать профессиональный уровень сотрудников, заниматься инновационными разработками.

    Разработка мероприятий, программ и планов

    Планирование

    1. Создание плана реорганизации.

    2. Планирование рабочего времени сотрудников.

    3. Создание маркетингового плана

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

    Организация

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

    1. Реорганизация имеющихся департаментов и отделов, создание новых функциональных единиц, модернизация нового штатного расписания.

    2. Разработка всех технических регламентов и формализация процессов.

    3. Написание детальных должностных инструкций

    4. Детальное распределение полномочий и распределение проектов. Назначение ответственного за результат.

    Мотивация

    В таблице 6 приводятся показатели качества трудовой жизни.

    Таблица контрольные работы опретивно-разыскные характеристики преступлений качества трудовой жизни

    ПоказательПоложение в данный момент
    Справедливая заработная плата
    Рыночная оплата трудаПрисутствует (но ближе к нижней планке). Есть институт премирования по итогам года и завешенных проектов, носит субъективный характер.
    Обоснованная дифференциация оплаты трудаВ зависимости от должности
    Индивидуальная ответственность за результаты внеклассная работа по окружающему миру трудаПрисутствует, начиная со среднего уровня, но никоим образом не отражается в оплате труда
    Доп. вознаграждение за длительный стаж работы в компанииФактически отсутствует
    Программа дополнительных выплат
    Выплата работнику и его семье в случае болезнида, по базовой ставке оплаты труда
    Оплачиваемое время по управлению персоналом с примерами в связи с праздниками и отпускамида, в соответствии с КЗОТ
    Оплачиваемые отпуска для дополнительного образованияОплачиваются в случае, если обучение происходит по направлению фирмы
    Условия безопасности труда и охраны здоровьяна уровне «здравого смысла»: все используемое оборудование в работе соответствует международным стандартам безопасности, офисные площади планируются из рекомендованных санитарных норм.
    Гарантия занятости
    Обеспечение непрерывности трудового стажада, в соответствии с КЗОТ
    Уверенность работников в своем будущемДа, стабильная компания, 15 лет на рыке.
    Развитие способностей работниковОбучение происходит стихийно или по необходимости.
    Социальная интеграция
    Социально-психологический микроклимат в организацииНейтральный. Много как позитивных, так и негативных моментов. Присутствует некая обособленность структурных единиц.
    Отношение руководства и подчиненныхМежду руководителями подразделений и подчиненными- ближе к демократическому.
    Участие работников в управлении производством и собственностью, поощрение инициатив и новых идей

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

    2. Управление собственностью: скорее исключает участие сотрудников в качестве партнеров по бизнесу.

    Исходя из перечисленных проблем в модели 7S и описания качества трудовой жизни – отсутствует формализованная система мотивации. Введен учёт по времени прихода на работу, но отсутствует фиксация отработанного времени (сотрудники часто работают по 12 часов - но отличительные положительные стороны дипломной работы пример не учитывается). Отсутствует система определения квалификации сотрудников. Определение вклада в общее дело носит субъективный характер иногда зависит от личных симпатий. Соответственно, необходимо разработать данную систему и утвердить ее на коллективном собрании сотрудников и учредителей.

    Контроль

    1. Внедрить в компании стандарты ISO9001, при необходимости разработать собственные стандарты качества. Ввести многоуровневые системы тестирования и контроля качества продуктов и услуг.

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

    3. Доработка внутренней ИС компании. Ведение отчетности, контроль выполнения и занятости, сравнительный анализ.

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

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

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

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

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


    2.Анализ и оптимизация бизнес-процессов

    2.1 Описание бизнес-процессов «как есть»

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

    Разработка

    Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

    - постановка задачи;

    - разработка;

    - тестирование;

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

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


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

    Диаграмма деятельности для стадии постановки задачи приведена на Рисунке 4.

    Рисунок 4. Диаграмма деятельности для стадии постановки задачи

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

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

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

    Контроль над процессом является эпизодическим, осуществляется в основном уже непосредственно перед сдачей проекта. Официальная оценка результатов разработки продукта отсутствует.

    Внедрение и сопровождение

    Процесс внедрения, а также последующего сопровождения прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 5):

    - установка ПО;

    - обучение пользователей;

    - сбор замечаний;

    - устранение замечаний;

    - модернизация ПО.

    Рисунок 5. Виды деятельности при внедрении и сопровождении


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

    В таблице 7 приведены сводные данные по ролям и функциям.

    Таблица 7.Сводная таблица ролей и функций

    ФункцияРольИтого
    разработчикспециалист по внедрениюдокументаторсотрудник тех. поддержкипользователь
    постановка задачи++++4
    разработка++2
    тестирование++++4
    документирование+++3
    сбор замечаний++++4
    устранение замечаний++2
    модернизация ПО++2
    обучение+++3
    установка ПО+++3
    Всего89325

    2.2 Проблемы и задачи

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

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

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

    - определение типа процесса для сопровождения существующих проектов;

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

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

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

    2.3 Анализ типовых вариантов процессов разработки

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

    На рисунке 6 приведен водопадный процесс разработки трудовые пенсии по случаю потери кормильца дипломная работа 2014 указанием результатов на каждом этапе.

    Рисунок 6. Водопадный процесс разработки

    Спиральный процесс

    В случае спирального процесса последовательность «анализ – проектирование – реализация – тестирование» выполняется несколько раз. Основные причины использования спирального процесса обычно следующие:

    - необходимость предупреждения рисков;

    - необходимость предоставить заказчику частичную версию проекта до его завершения.

    Основной трудностью использования спирального процесса является поддержка актуальности документации.

    На рисунке 7 приведен спиральный процесс разработки.

    Рисунок 7. Спиральный процесс разработки

    Инкрементальный процесс

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

    Унифицированный процесс

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

    На рисунке 8 приведен унифицированный процесс разработки.

    Рисунок 8. Унифицированный процесс разработки

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

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

    - для сопровождения – использование инкрементального процесса.

    2.4 Оптимизация процессов разработки и сопровождения

    При переходе к проектному управлению необходима реорганизация бизнес-процессов в соответствии с жизненным циклом реализации проектов. Жизненный цикл проекта – это комбинация процессов и подпроцессов, необходимых для создания (реализации) объекта или решения. Так, жизненный цикл проекта в стандарте PMI (ProjectManagementInstitute, США) состоит из следующих фаз:

    - начальная фаза (инициирование проекта);

    - разработка;

    - реализация;

    - завершение.

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

    Фазы могут обладать следующими характеристиками:

    - границы;

    - вход, выход;

    - длительность;

    - операции;

    - участники;

    - бюджеты.

    Проблематика управления проектами в современном менеджменте подробно разработана и доведена до стандартов. В стандартах проектного управления PMI жизненный цикл проекта разбивается на следующие типовые этапы:

    - процесс инициирования – принятие решения о начале выполнения проекта;

    - процесс планирования – определение целей и критериев успеха проекта и разработка рабочих схем их достижения;

    - процесс исполнения – координация людей и других ресурсов для выполнения плана;

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

    - процесс управления – определение корректирующих воздействий, их согласование, утверждение и применение;

    - процесс завершения – формализация выполнения проекта и приведение его к упорядоченному финалу.

    Процессы управления проектами приведены на рисунке 9.


    Рисунок 9. Процессы управления проектами

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

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

    - временной регламент;

    - рецензия на дипломную работу пенсионное обеспечение недостатки участники.

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

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

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

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

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

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

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

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

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

    В рамках данной работы рассматриваются две группы процессов:

    - проекты по разработке на тему политика как об прикладных систем;

    - проекты по сопровождению существующих систем.

    Первая группа проектов полностью соответствует общепринятому пониманию термина «проект», т.к. в результате производится уникальный продукт – новая прикладная система, которая в дальнейшем может пойти в массовое распространение, внедрение и сопровождение.

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

    3.Результаты и рекомендации

    3.1 Описание бизнес-процессов «как должно быть

    Жизненный цикл нового проекта представлен на диаграмме деятельности (Рисунок 10).

    Рисунок 10. Жизненный цикл нового проекта

    Создание Устава проекта

    Устав проекта – официальный письменный документ, который формально признает и подтверждает факт существования проекта. Создание Устава проекта позволяет достичь следующих целей:

    - официальное подтверждение начала реализации проекта;

    - выделение проектных ресурсов;

    - обеспечение единства целей;

    - назначение руководителя проекта;

    - изложение общего содержания и целей проекта;

    - определение масштаба проекта и количества итераций.

    Документы на входе:

    - имеющаяся исходная документация по проекту (контракт, постановка задачи, общее описание и пр.).

    Документы на выходе:

    - Устав проекта.

    Временной регламент:

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

    Операции:

    - определение общего содержания проекта;

    - определение целей и задач проекта;

    - определение требований;

    - коммерческое обоснование;

    - оценка затрат и ресурсов;

    - анализ платежеспособности коммерческой организации с примером баланса функций и обязанностей.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Определение плана итераций

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

    Документы на входе:

    - Устав проекта.

    Документы на выходе:

    - План итераций.

    Временной регламент:

    - 1-5 дней.

    Операции:

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

    - определение результатов каждой итерации.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Планирование итерации

    Итерации планируются последовательно, в каждый момент времени известен план текущей итерации. При высокой степени определенности проекта возможно планирование текущей и следующей итераций. Для каждой итерации определяются проводимые стадии и сроки их завершения. Следует учесть, что желательно на разработку выделить около 1/6 общей длительности итерации, наиболее длительная стадия – проектирование.

    Документы на входе:

    - Устав проекта;

    - План итераций.

    Документы на выходе:

    - План следующей итерации.

    Временной регламент:

    - 1-5 дней.

    Операции:

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

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

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

    - определение ресурсов и ответственных.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Планирование каждой стадии

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

    Документы на входе:

    - План текущей итерации;

    - Результаты предыдущей итерации;

    - Результаты предыдущей стадии.

    Документы на выходе:

    - План текущей стадии.

    Временной регламент:

    - 1-2 дня.

    Операции:

    - декомпозиция стадии на задачи;

    - определение сроков завершения каждой задачи;

    - определение ресурсов и ответственных.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Выполнение каждой стадии

    Выполнение каждой стадии происходит параллельно с планированием следующей стадии (при ее наличии).

    Документы на входе:

    - План текущей стадии.

    Документы на выходе:

    - для стадии анализа:

    o постановка задачи (ТЗ и пр.) (образец документа приведен в Приложении 1);

    o тестовый пример (образец документа приведен в Приложении 1);

    - для стадии проектирования:

    o технический проект (образец документа приведен в Приложении 1);

    - для стадии реализации:

    o описание реализации (образец документа приведен в Приложении 1);

    o краткое руководство (образец документа приведен в Приложении 1);

    - для стадии тестирования:

    o отчет о тестировании (образец документа приведен в Приложении 1);

    o ведомость замечаний (образец документа приведен в Приложении 1);

    o отчет об устранении замечаний (образец документа приведен в Приложении 1).

    Временной регламент:

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

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

    Операции:

    - выполнение задачи;

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

    Участники:

    - руководитель проекта;

    - исполнители задач.

    Контроль исполнения

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

    Документы на входе:

    - Устав проекта;

    - План итераций;

    - План текущей итерации;

    - План текущей стадии;

    - Результаты выполнения задач:

    o постановка задачи;

    o тестовый пример;

    o технический проект;

    o описание реализации;

    o краткое руководство;

    o отчет о тестировании;

    o ведомость замечаний;

    o отчет об устранении замечаний.

    Документы на выходе:

    - Устав проекта;

    - План итераций;

    - План текущей итерации;

    - План текущей стадии.

    Временной регламент:

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

    Операции:

    - контроль сроков;

    - контроль качества результатов;

    - перераспределение ресурсов;

    - внесение изменений в планы;

    - внесение изменений в Устав проекта;

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

    Участники:

    - на тему монтаж дверного блока проекта;

    - исполнители задач.

    Завершение проекта

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

    Документы на входе:

    - полный объем проектной документации.

    Документы на выходе:

    - архив проектных документов;

    - замечания и предложения по проекту.

    Временной регламент:

    - 5-10 дней; также зависит от сроков окончательных расчетов.

    Операции:

    - финальные процедуры контроля проекта;

    - закрытие контрактов, проведение расчетов;

    - формирование замечаний и предложений по проекту;

    - архивирование проектной документации.

    Участники:

    - руководитель проекта;

    - проектная группа и прочие заинтересованные лица.


    Проекты по сопровождению

    Жизненный цикл проекта по сопровождению представлен на диаграмме деятельности (Рисунок 11) отзыв научного руководителя на по маркетингу указанием входной и выходной информации и ролей пользователей.

    Рисунок 11. Жизненный цикл проекта по сопровождению

    Создание Устава проекта

    Документы на входе:

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

    Документы на выходе:

    - Устав проекта.

    Временной регламент:

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

    Операции:

    - определение общего содержания проекта;

    - определение целей и задач проекта;

    - определение порядка сопровождения;

    - определение плана выпуска обновлений их объема;

    - коммерческое обоснование;

    - оценка затрат и ресурсов;

    - определение функций и обязанностей.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Определение плана выпуска обновлений

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

    Документы на входе:

    - Устав проекта.

    Документы на выходе:

    - План выпуска обновлений.

    Временной регламент:

    - 1-2 дня.

    Операции:

    - определение сроков выпуска обновлений;

    - определение объема обновлений.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Планирование итерации

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

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

    Документы на входе:

    - План выпуска обновлений;

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

    Документы на выходе:

    - План итерации.

    Временной регламент:

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

    Операции:

    - рассмотрение заявки;

    - включение заявки в план;

    - декомпозиция плана на задачи;

    - определение сроков завершения каждой задачи;

    - определение ресурсов и ответственных.

    Участники:

    - руководитель проекта.

    Выполнение итерации

    Выполнение итерации происходит параллельно с планированием следующей итерации (при ее наличии).

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

    - План текущей разработка программного обеспечения на примере дипломная работа на выходе:

    - для стадии анализа:

    o заявка (образец документа приведен в Приложении 1);

    o тестовый пример (образец документа приведен в Приложении 1);

    - для стадии проектирования:

    o технический проект;

    - для стадии реализации:

    o описание реализации (образец документа приведен в Приложении 1);

    o краткое руководство (образец документа приведен в Приложении 1);

    - для стадии тестирования:

    o отчет о тестировании (образец документа приведен в Приложении 1);

    o ведомость замечаний (образец документа приведен в Приложении 1);

    o отчет об устранении замечаний (образец документа приведен в Приложении 1);

    - для стадии внедрения:

    o отчет об установке обновления/программного обеспечения (образец документа приведен в Приложении 1);

    o ведомость обучения (образец документа приведен в Приложении 1).

    Временной регламент:

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

    Операции:

    - выполнение задачи;

    - подготовка и согласование результирующих документов;

    - переход разработка программного обеспечения на примере дипломная работа следующую стадию.

    Участники:

    - руководитель проекта;

    - исполнители задач.

    Контроль исполнения

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

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

    Общий и детализированный план должен быть доступен всем заинтересованным лицам.

    Документы на входе:

    - Устав проекта;

    - План выпуска обновлений;

    - Планы итераций;

    - Результаты выполнения задач:

    o заявка;

    o тестовый пример;

    o технический проект;

    o описание реализации;

    o краткое руководство;

    o отчет о тестировании;

    o ведомость замечаний;

    o отчет об устранении замечаний;

    o отчет об установке обновления/программного обеспечения;

    o ведомость обучения.

    Документы на выходе:

    - Устав проекта;

    - План выпуска обновлений;

    - Планы итераций.

    Временной регламент:

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

    Операции:

    - контроль сроков;

    - контроль качества результатов;

    - перераспределение ресурсов;

    - внесение изменений в планы;

    - внесение изменений в Устав проекта;

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

    Участники:

    - руководитель проекта;

    - исполнители задач.

    Завершение проекта

    Документы на входе:

    - полный объем проектной документации.

    Документы на выходе:

    - архив проектных документов;

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

    Временной регламент:

    - 5-10 дней; также зависит от сроков окончательных расчетов.

    Операции:

    - финальные процедуры контроля проекта;

    - закрытие контрактов, проведение расчетов;

    - формирование замечаний и предложений по проекту;

    - архивирование проектной документации.

    Участники:

    - руководитель проекта;

    - проектная группа и прочие заинтересованные лица.

    Управление ходом проекта

    Процесс перехода между стадиями

    В процессе перехода продукта с одной стадии на другую в рамках текущей итерации, как правило, происходит тесное взаимодействие между исполнителями этих стадий (Рисунок 12).

    Рисунок 12. Взаимодействие между исполнителями стадий

    В то время, пока стадии «перекрываются» (зеленая зона на рисунке), темы для дипломных работ по тарифам взаимодействие является необходимым для того, чтобы исполнители следующей стадии получили ответы на все возникающие вопросы.

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

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

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

    Для упорядочивания процесса разработки продуктов предлагается следующий порядок:

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

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

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

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

    Документирование процесса перехода между стадиями

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

    Рисунок 13. Документирование процесса перехода между стадиями

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

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

    Если исправления вносятся на текущей стадии:

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

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

    Образцы и краткое содержание документов, указанных на рисунке, приведены в Приложении 1.

    Процесс перехода между итерациями

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

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

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

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

    - пронумерованные версии всех проектных документов на момент завершения итерации.

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

    Процесс перехода продукта из разработки во внедрение и сопровождение

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

    - ознакомление с проектной документацией;

    - демонстрация программного продукта;

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

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

    Оценка деятельности

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

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

    Документ «Ведомость замечаний» свидетельствует о наличии вопросов и замечаний со стороны исполнителей какой-либо стадии к результатам предыдущей стадии. Чаще всего это также свидетельствует о низком качестве результатов, реже – о недостаточной квалификации исполнителей текущей стадии.

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

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

    3.2 Изменения в разработка программного обеспечения на примере дипломная работа структуре

    Изменения в организационно-штатной структуре представлены на рисунке 14.

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

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

    Все структурные подразделения, занимающиеся разработкой, объединяются в Дипломная работа на тему удлиненное каре разработки. В том числе выделяется Управление развития инструментальных средств и Управление разработки прикладных систем. Первое подразделение занимается инструментарием для разработки прикладных систем, второе же – непосредственно разработкой прикладных систем. В состав Центра также входит Управление проектирования.

    Все подразделения, ответственные за внедрение и сопровождение, объединяются в Департамент сопровождения.

    В состав Департамента системной интеграции включены подразделения, ответственные за техническую поддержку, ИТ-инфраструктуру, дизайн и рекламу.

    Также отдельно выделен Департамент профессионального развития персонала.

    Рисунок 14. Новая организационно-штатная структура

    3.3 Регламентирование деятельности

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

    Регламентированию подверглись в первую очередь следующие процессы:

    - Оперативный мониторинг информационная поддержка хода исполнения контрактных обязательств (Регламент приведен в Приложении 2);

    - Разработка программного обеспечения и выпуск дистрибутивов (Регламент приведен в Приложении 3);

    - Исполнение заявок на обслуживание и сопровождение (Регламент приведен в Приложении 4).

    Регламенты являются определяющими документами при выполнении указанных процессов.

    Помимо регламентов, были разработаны типовые должностные инструкции (образец приведен в Приложении 5), а также квалификационные требования к сотрудникам компании (образец приведен в Приложении 6), что позволит упорядочить и организовать процессы, связанные с движением кадров в компании.

    3.4 Перспективные направления автоматизации

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

    Приоритетными являются нижеуказанные направления.

    Информационная поддержка исполнения контрактных обязательств:

    - учетные сведения о клиентах;

    - реестр контрактов;

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

    Кадровый учет:

    - штатная структура компании;

    - личные карточки сотрудников;

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

    - табельный учет.

    Делопроизводство и документооборот:

    - входящая исходящая корреспонденция;

    - создание, согласование и утверждение внутренней документации;

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

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

    - учет дистрибутивов и стадий их выпуска;

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

    - учет разовых обновлений;

    - учет установленных у клиентов версий дистрибутивов.

    Информационная поддержка процессов разработки, внедрения, сопровождения, технической поддержки:

    - планирование деятельности;

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


    Заключение

    Поставленная задача оптимизации бизнес-процессов была решена в полном объеме; оптимизации подверглись основные процессы деятельности организации, а именно разработка, внедрение и сопровождение программного обеспечения.

    Источник: http://www.bestreferat.ru/referat-213145.html
    Категория
    Реклама
    Тип
    курсовая работа
    Страницы
    1 стр.
    Дата
    07.05.2013
    Формат файла
    .rtf — Rich Text Format (Wordpad)
    Архив
    512816.zip — 98.45 kb
    • razrabotka-rekomendacij-po-sovershenstvovaniju-strategii-materialno-texnicheskogo-obespech_512816_1.rtf — 1063.42 Kb
    • Readme_docus.me.txt — 125 Bytes
    Оцените работу
    Хорошо  или  разработка программного обеспечения на примере дипломная работа Плохо

      Скачать




    Источник: http://docus.me/d/512816/

    Оригинальная работа - системы

    СЕЙЧАС ПРОСМАТРИВАЮТ:
    то и ремонт трансмиссии зил 130



    Курсовая работа

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

    Содержание

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

    Введение

    1.Стратегический анализ деятельности компании

    1.1 Обоснование выбора организации

    1.2 Организационно-штатная структура

    1.3 Основные проблемы управления

    1.4 Постановка стратегических целей

    1.5 Анализ и выбор стратегии

    2.анализ и оптимизация бизнес-процессов

    2.1 Описание бизнес-процессов «как есть»

    2.2 Проблемы и задачи

    2.3 Анализ типовых вариантов процессов разработки

    2.4 Оптимизация процессов разработки и сопровождения

    3.Результаты и рекомендации

    3.1 Описание бизнес-процессов «как должно быть»

    3.2 Изменения в организационно-штатной структуре

    3.3 Регламентирование деятельности

    3.4 Перспективные направления автоматизации

    Заключение

    Список использованной литературы

    Приложение

    Образцы внутренних документов

    Приложение

    Регламент оперативного мониторинга информационной поддержки хода исполнения контрактных обязательств

    Приложение

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

    Приложение

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

    Приложение

    Типовая должностная инструкция специалиста-стажера Управления разработки прикладных систем

    Приложение

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


    Введение

    Данная аттестационная работа направлена на описание и оптимизацию бизнес-процессов компании-разработчика программного обеспечения (далее – ПО).

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

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

    Целью данной работы является выработка стандартов работы компании и оптимизация существующих бизнес-процессов. В работе необходимо выполнить следующие задачи:

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

    - описание текущего положения и штатной структуры компании;

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

    - оптимизация штатной структуры компании;

    - анализ проблем и выработка решений по управленческим и кадровым проблемам компании;

    - создание образцов типовых документов;

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

    1.Стратегический разработка программного обеспечения на примере дипломная работа деятельности компании

    1.1 Обоснование выбора организации

    ВкачествеисследуемойорганизациивыбранаООО«Кварта».

    Основными направлениями деятельности компании являются:

    - разработка программного обеспечения (ПО);

    - внедрение и сопровождение программного обеспечения;

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

    При этом разработка ПО ведется в двух направлениях – ПО сферы бухгалтерского учета разрабатывается на одной платформе, а ПО остальных направлений – на другой (т.н. ИИС).

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

    Организационно-штатная структура компании еще больше усугубляет вышеуказанные проблемы.

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

    Описание организации приведено в Таблице 1.


    Таблица 1.Описание организации как объекта управления

    Параметр описанияХарактеристика
    Название, местонахождениеООО «Кварта», г. Москва
    НазначениеОказание услуг автоматизации для федеральных и территориальных органов государственной власти, бюджетных учреждений, а также для малых и средних предприятий (разработчик и поставщик разработка программного обеспечения на примере дипломная работа по внедрению разработка программного обеспечения на примере дипломная работа сопровождению автоматизированных информационных систем (АИС), системная интеграция)
    Отраслевая принадлежность

    Отрасли третичного цикла

    Частная фирма

    Информационные технологии

    Правовая форма и вид собственностиКоммерческое предприятие, общество с ограниченной ответственностью, частное
    Историческая справка

    Образовалась в 1993 году. Первый заказчик Управление делами Президента РФ Начало создания финансово-бухгалтерской системы, организация ЛВС. Постепенно в компании образовался ряд направлений деятельности, которые впоследствии переросли в отдельные компании («Кварта-технологии», «Кварта-сети», «Кварта-консалтинг», Кадровое агентство «Кварта», «Сенсорные системы» и др.). Непосредственно сама компания занялась разработкой интегрированных информационных систем управления предприятием (ИИС), а также комплексной автоматизацией организаций и предприятий. Основным направлением деятельности были выбраны федеральные органы законодательной исполнительной власти РФ. На данный момент заказчиками услуг компании являются Аппарат Правительства, Государственная Дума, Совет Федерации, Счётная палата, УД Президента РФ и большая часть Министерств, федеральных служб и агентств, включая подведомственные организации и загранучреждения, а также коммерческие организации различных форм собственности.

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

    Организационная структураСм. ниже (Модель «Цепочки ценностей»)
    Структура управленияВ данный момент компания использует вертикальную систему управления от генерального директора к руководителям структурных подразделений (департаментов), часть из которых выполняет функции заместителей, далее к начальникам отделов и групп. Подразделения поделены по функциональному признаку. В последнее время в связи с большим количеством разнородных проектов, требующих шаблон страницы для дипломных работ разных направлений, постепенно вводится практика назначения руководителей проектов (как правило руководители отделов) и планируется серьёзная структурная реорганизация.
    Параметр описанияХарактеристика
    Ресурсы

    Основной ресурс – сотрудники. Поощрение инициативных сотрудников, дружеская атмосфера в коллективе. Большое внимание уделяется обучению.

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

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

    Многолетний опыт работы и большое количество завершенных проектов, что позволяет участвовать и выигрывать конкурсы.

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

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

    Законодательство: Изменчивое законодательство, постоянные нововведения, часто не подкреплённые методическими рекомендациями, ограниченное время на реализацию изменений.

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

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

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

    Руководство

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

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

    Параметр описанияХарактеристика
    Модель «Цепочки ценностей»

    Процессы основной деятельности:

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

    Интеграция: полный комплекс услуг, начиная с этапа сбора информации и проектирования, до сдачи в эксплуатации функционирующих в соответствии с требованиями заказчика программно-аппаратных комплексов

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

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

    Предоставление услуг: также компания специализируется на предоставлении услуг по обслуживанию компаний, с уже работающей аппаратно-программной инфраструктурой, осуществляет, разрабатывает заказные продукты.

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

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

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

    Поддержка программно-аппаратной части компании

    Управление персоналом (мотивация, обучение и пр.)

    Снабжение

    Внутренний финансово-бухгалтерский учёт

    Технологические исследования

    Делопроизводство

    1.2 Организационно-штатная структура

    Существующая штатная структура организации приведена на Рисунке 1.

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

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

    Кадровая служба не существует в виде отдельного подразделения.

    Рисунок 1. Существующая штатная структура.


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

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

    1.3 Основные проблемы управления

    В рассматриваемой организации существует ряд нижеперечисленных проблем управления.

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

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

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

    Наличие 2-х направлений разработки программных продуктов, часто имеющих схожий функционал. Отсутствие общей концепции, что приводит к дублированию, а часто и несовместимости собственных разработок. Также налицо неэффективное использование ресурсов. Это влечёт за собой дополнительный штат внедренческого разработка программного обеспечения на примере дипломная работа планирования. Часто приводит к авральному выполнению проектов и нехватке сотрудников.

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

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

    1.4 Постановка стратегических целей

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

    Миссия

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

    Стратегический профиль

    Текущую стратегию я бы сформулировал следующим образом:

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

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

    Видение (стратегическое намерение)

    1. Какой мы хотим видеть свою организацию в будущем?

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

    2. Что из себя представляет разработка программного обеспечения на примере дипломная работа бизнес сейчас и каким он будет в будущем?

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

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

    3. Кто является потребителями нашей продукции (услуг) и на какую разработка программного обеспечения на примере дипломная работа покупателей организация будет ориентироваться в будущем?

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

    4. Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей?

    Следовать последним тенденциям в области разработки. Провести реинжиниринг в соответствии с требованиями ISO9001 и пройти сертификацию. Повысить качество продукта путем улучшения качества проектирования и ввода многоуровневой системы тестирования. Уделять больше внимания вопросам информационной безопасности. Создать консолидированную систему отчётности и базу знаний. Улучшить качество управления персоналом для повышения эффективности.

    Стратегические цели

    1. Сроки стратегического планирования.

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

    2. Генеральная цель.

    В течение 2-х лет отказаться реферат бюджетная политика рф на современном этапе разработки двух линеек продуктов, перевести их на единую интегрированную платформу, сделать продукт современным и качественным, требующим малых трудозатрат на сопровождение.

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

    - Завершить реорганизацию структуры (создание новых структурных подразделений и распределение функций между ними)

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

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

    Повысить профессиональный уровень сотрудников

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

    - Внедрить систему аттестации сотрудников

    - Организовать процесс повышения профессиональной подготовки кадров

    - Проведение тематических семинаров

    Формализовать процессы.

    - Разработать должностные инструкции, ввести четкое разграничение полномочий

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

    - Организовать процесс документирования производимых работ

    - Стандартизировать процессы планирования и отчётности

    1.5 Анализ и выбор стратегии

    Результаты SWOT-анализа приведены в таблице 2 и таблице 3.

    Таблица 2.Анализ факторов, воздействующих на достижение стратегических целей

    ФакторыШифрСодержаниеОценка
    Сильные стороны организацииS1Сплоченный, высокопрофессиональный коллектив.7
    S2Хорошая технологическая база, финансовая независимость6
    S3Актуальные инновационные разработки, учитывающие специфику рынка8
    S4Отличная репутация и долгов время пребывания на рынке9
    Итого30
    Слабые стороны организацииW1Две линейки однородных продуктов, одна из которых использует устаревшую платформу7
    W2Низкий уровень менеджмента организации, структура, не отвечающая текущим требованиям8
    W3Отсутствие маркетинговой политики и долгосрочного планирования6
    Итого21
    Возможности окружающей средыO1Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО7
    O2Наличие действующих контрактов, необходимых связей, владение анализ имущественного положения предприятия дипломная работа информацией9
    O3Увеличение финансирования по программе «Электронная Россия», рост ИТ-рынка в целом8
    Итого24
    Угрозы окружающей средыT1Снижение финансирования госсектора, финансовые потрясения4
    T2Риск активизации текущих игроков рынка6
    T3Зависимость от тенденций рынка в области платформ разработки8
    Итого18

    Таблица 3.Итоговая стратегическая матрица

    Сильные стороны организацииСлабые стороны организации
    S1S2S3S4W1W2W3
    Возможности

    S3-O2 Увеличение объемов поставок решений заказчикам

    S4-O3 Рост количества клиентов

    S1-O3 Расширение линейки продуктов

    S3-O1 Практически монополия по ряду поставляемых задач

    S2-O2 Возможность работы в кредит

    S4-O1 Возможность получения дополнительных разрешений

    S2-O1 Возможность выпускать продукты с соотв. с самыми современными технологиями

    W1-O3 Использовать средства для модернизации линейки продуктов, вкладывать в новые технологии

    W3-O2 Возможность планирования работ заранее, оптимальное "разработка программного обеспечения на примере дипломная работа" ресурсов

    W1-O1 Использование партнёрской поддержки для скорейшего освоения последних технологий

    W2-O3 Реорганизация системы управления, поиск профессиональных кадров

    O1
    O2
    O3
    Угрозы

    S1-T1 Возможность текучки кадров. Повышать разработка программного обеспечения на примере дипломная работа, постоянный мониторинг.

    S2-T1 Не терять финансовую независимость, что позволит существовать в кризисные моменты достаточно продолжительное время, предоставлять возможность работы в кредит

    S3-T3 Постоянно отслеживать изменение технологий, заниматься перспективными разработками.

    S4-T2 Повышать авторитет, активно участвовать в конкурсах, отслеживать изменения стратегии у конкурентов

    S2-T2 выпускать новый продукт раньше, чем конкуренты

    W1-T3(Т1) Как можно скорее перейти на более совершенную платформу

    W3-T1(Т2) Отслеживать состояние рынка, тщательно планировать деятельность

    W2-T2 Привести структуру в соответствие с возникшей необходимостью, повышать квалификацию менеджеров

    T1
    T2
    T3
    T4

    Граф типовых стратегий организации приведен на рисунке 2.

    Рисунок 2. Граф типовых стратегий

    Выбор и обоснование стратегии

    В таблице 4 приведен выбор и оценка факторов, задействованных в трёх базовых стратегиях.

    Таблица 4.Выбор и оценка факторов, задействованных в трёх базовых стратегиях

    ФакторыОценкаРеструктуризация (лидерство по издержкам)ДифференциацияКомбинированная стратегия
    Удельный вес фактораСредне-взвешенная оценка фактораУдельный вес фактораСредне-взвешенная оценка фактораУдельный вес фактораСредне-взвешенная оценка фактора
    S170,10,70,10,70,10,7
    S260,150,90,21,20,181,08
    S380,10,80,2520,171,36
    S490,151,350,252,250,21,8
    W170,151,050,050,350,10,7
    W280,151,30,10,80,120,96
    W360,21,20,050,30,130,78
    Итого17,317,617,38
    O170,151,050,21,40,171,19
    O290,151,350,21,80,171,53
    O380,151,20,2520,21,6
    T140,20,80,050,20,130,52
    17T260,21,20,150,90,181,08
    T380,151,20,151,20,151,2
    Итого16,817,517,12

    По сумме оценок:

    По сумме оценок наилучшей стратегией является стратегия дифференциации.

    По реальности задействованных факторов:

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

    Выбранная стратегия

    Возможные действия в рамках реализации стратегии:

    - Совершенствование и расширение линейки продуктов

    - Повышение профессионального уровня сотрудников

    - Повышение значимости планирования.

    - Агрессивная маркетинговая политика расширение партнёрских отношений.

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

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

    К недостаткам можно отнести следующее:

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

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

    Реализация системы планов. Эффективность изменений

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

    Таблица 5.Определение необходимых изменений

    ШифрНаименованиеВес7SРеакция
    S1Сплоченный, высокопрофессиональный коллектив.0,8Shared ValuesДержать уровень оплаты труда на рыночном уровне, предоставлять бонусы и гарантии. Разработать программы мотивации и повышения квалификации персонала, ввести аттестацию.
    S2Хорошая технологическая база, финансовая независимость0,7SkillsТехнологическая база должна соответствовать современному уровню, обновлять при необходимости, использовать имеющиеся возможности разработка программного обеспечения на примере дипломная работа привлечения перспективных клиентов (кредит…)
    S3Актуальные инновационные разработки, учитывающие специфику рынка1,4SkillsПоддерживать высокое качество продуктов, уделять больше внимания заказчикам. Донести до потенциальных заказчиков преимущества (маркетинговая программа), всегда быть в курсе последних изменений, выводить на рынок продукты раньше конкурентов.
    S4Отличная репутация и долгов время пребывания на рынке1,7

    Strategy

    Skills

    W1Две линейки однородных продуктов, одна из которых использует устаревшую платформу0,7

    Strategy

    Skills

    Отказаться от разработки двух линеек продуктов, перевести их на единую интегрированную платформу, сделать продукт современным и качественным. Постоянно проводить инновационные исследования и создать непрерывный цикл периодических обновлений.
    W2Низкий уровень менеджмента организации, структура не отвечающая текущим требований1,2

    Systems

    Style

    Structure

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

    W3Отсутствие маркетинговой политики и долгосрочного планирования1

    Skills

    Strategy

    Разработка маркетинговой стратегии. Выработка стратегических планов и направлений развития компании на основе имеющихся знаний и возможностей.
    O1Наличие лицензий и разрешений разработка программного обеспечения на примере дипломная работа органов, партнёрство с поставщиками СУБД и системного ПО1,4SkillsРазвивать партнёрские отношения с поставщиками. Лицензировать деятельность и обеспечивать наличие разрешений во всех требуемых направлениях.
    O2Наличие действующих контрактов, необходимых связей, владение необходимой информацией1,7

    Strategy

    Обеспечивать качественное выполнение контрактов с целью их продления, расширения услуг и повышения репутации. Расширять связи с разработка программного обеспечения на примере дипломная работа своевременного получения информации.
    O3Увеличение финансирования по программе «Электронная Россия», рост ИТ рынка в целом1,6

    Strategy

    Развивать маркетинговую политику, активно участвовать в конкурсах, предлагать качественные, функциональные, опережающие конкурентов продукты
    T1Снижение финансирования госсектора, финансовые потрясения1,2

    Strategy

    Shared Values

    Иметь резервные фонды и возможность предоставления услуг в кредит, широкий спектр продуктов и услуг. Поддерживать коллективный дух и корпоративные ценности.
    T2Риск активизации текущих игроков рынка0,7StrategyВести активный мониторинг рынка. Владеть информацией. Иметь широкую продуктовую линейку с сильными конкурентными преимуществами.
    T3Зависимость от тенденций рынка в области платформ разработки1

    Skills

    Strategy

    Активно сотрудничать с поставщиками, развивать партнёрские отношения. Повышать профессиональный уровень сотрудников, заниматься инновационными разработками.

    Разработка мероприятий, программ и планов

    Планирование

    1. Создание плана реорганизации.

    2. Планирование разработка программного обеспечения на примере дипломная работа времени сотрудников.

    3. Создание маркетингового плана

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

    Организация

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

    1. Реорганизация имеющихся департаментов и отделов, создание новых олимпийские игры древней греции: возникновение и развитие. единиц, модернизация нового штатного расписания.

    2. Разработка всех технических регламентов и формализация процессов.

    3. Написание детальных должностных инструкций

    4. Детальное распределение полномочий и распределение проектов. Назначение ответственного за результат.

    Мотивация

    В таблице 6 приводятся показатели качества трудовой жизни.

    Таблица 6.Показатели качества трудовой жизни

    ПоказательПоложение в данный момент
    Справедливая заработная плата
    Рыночная оплата трудаПрисутствует (но ближе к нижней планке). Есть институт премирования по итогам года и завешенных проектов, носит субъективный характер.
    Обоснованная дифференциация оплаты трудаВ зависимости от должности
    Индивидуальная ответственность за результаты общего трудаПрисутствует, начиная со среднего уровня, но никоим образом не отражается в оплате труда
    Доп. вознаграждение за длительный стаж работы в компанииФактически отсутствует
    Программа дополнительных выплат
    Выплата работнику и его семье в случае болезнида, по базовой ставке оплаты труда
    Оплачиваемое время отпуска в связи с праздниками и отпускамида, в соответствии с КЗОТ
    Оплачиваемые отпуска для дополнительного образованияОплачиваются в случае, если обучение происходит по направлению фирмы
    Условия безопасности труда и охраны здоровьяна уровне «здравого смысла»: все используемое оборудование в работе соответствует международным стандартам безопасности, офисные площади планируются из рекомендованных санитарных норм.
    Гарантия занятости
    Обеспечение непрерывности трудового стажада, в соответствии с КЗОТ
    Уверенность работников в своем будущемДа, стабильная компания, 15 лет на рыке.
    Развитие способностей работниковОбучение происходит стихийно или по необходимости.
    Социальная интеграция
    Социально-психологический микроклимат в организацииНейтральный. Разработка программного обеспечения на примере дипломная работа как позитивных, так и негативных моментов. Присутствует некая обособленность структурных единиц.
    Отношение руководства и подчиненныхМежду руководителями подразделений и подчиненными- ближе к демократическому.
    Участие работников в управлении производством и собственностью, поощрение инициатив и новых идей

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

    2. Управление собственностью: скорее исключает участие сотрудников в качестве партнеров по бизнесу.

    Исходя из перечисленных проблем в модели 7S разработка программного обеспечения на примере дипломная работа описания качества трудовой жизни – отсутствует формализованная система мотивации. Введен учёт по времени прихода на работу, но отсутствует фиксация отработанного времени (сотрудники часто работают по 12 часов - но это не учитывается). Отсутствует система определения квалификации сотрудников. Определение вклада в общее дело носит субъективный характер иногда зависит от личных симпатий. Соответственно, необходимо разработать данную систему и утвердить ее на коллективном собрании сотрудников разработка программного обеспечения на примере дипломная работа учредителей.

    Контроль

    1. Внедрить в компании стандарты ISO9001, при необходимости разработать собственные стандарты качества. Ввести многоуровневые системы тестирования и контроля качества продуктов и услуг.

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

    3. Доработка внутренней ИС компании. Ведение отчетности, контроль выполнения и занятости, сравнительный анализ.

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

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

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

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

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


    2.Анализ и оптимизация бизнес-процессов

    2.1 Описание бизнес-процессов «как есть»

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

    Разработка

    Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

    - постановка задачи;

    - разработка;

    - тестирование;

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

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


    В стадии постановки задачи (например, написание ТЗ) участвуют как представители заказчика, так и сотрудники компании. При этом постановкой занимаются не профессиональные аналитики, а все, кто имеет хотя бы косвенное отношение к тематике: разработчики, внедренцы, документаторы.

    Диаграмма деятельности разработка программного обеспечения на примере дипломная работа стадии постановки задачи приведена на Рисунке 4.

    Рисунок 4. Диаграмма деятельности для стадии постановки задачи

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

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

    Процессы непосредственно разработки, а также последующего тестирования и документирования не формализованы. Чаще всего выбираются минимально необходимые свободные ресурсы, которым и передается ТЗ. Разработкой могут заниматься не только разработчики, но и специалисты по внедрению, чья квалификация дипломные и курсовые работы по юриспруденции выполнять какие-либо дополнительные задания по разработке. Процедура тестирования является необязательной, модульное тестирование осуществляется по желанию инициативе разработчика. Тестирование конечного продукта чаще всего проводится в процессе документирования, либо уже непосредственно при внедрении и обучении пользователей. Документирование также проводится по инициативе разработчика, однако, если условия контракта требуют предоставления комплекта документации, документированием может заниматься также документатор (при наличии свободных ресурсов) либо специалист по внедрению.

    Контроль над процессом является эпизодическим, осуществляется в основном уже непосредственно перед сдачей проекта. Официальная оценка результатов разработки продукта отсутствует.

    Внедрение и сопровождение

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

    - установка ПО;

    - обучение пользователей;

    - сбор замечаний;

    - устранение замечаний;

    - модернизация ПО.

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

    В таблице 7 приведены сводные данные по ролям и функциям.

    Таблица 7.Сводная таблица ролей и функций

    ФункцияРольИтого
    разработчикспециалист по внедрениюдокументаторсотрудник тех. поддержкипользователь
    постановка задачи++++4
    разработка++2
    тестирование++++4
    документирование+++3
    сбор замечаний++++4
    устранение замечаний++2
    модернизация ПО++2
    обучение+++3
    установка ПО+++3
    Всего89325

    2.2 Проблемы и задачи

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

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

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

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

    - определение типа процесса для сопровождения существующих проектов;

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

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

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

    2.3 Анализ типовых вариантов процессов разработки

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

    На рисунке 6 приведен водопадный процесс разработки с указанием результатов на каждом этапе.

    Рисунок 6. Водопадный процесс разработки

    Спиральный процесс

    В случае спирального процесса последовательность «анализ – проектирование – реализация – тестирование» выполняется несколько раз. Основные причины использования спирального процесса обычно следующие:

    - необходимость предупреждения рисков;

    - необходимость предоставить заказчику частичную версию проекта до его завершения.

    Основной трудностью использования спирального процесса является поддержка актуальности документации.

    На рисунке 7 приведен спиральный процесс разработки.

    Рисунок 7. Спиральный процесс разработки

    Инкрементальный процесс

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

    Унифицированный процесс

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

    На рисунке 8 приведен унифицированный процесс разработки.

    Рисунок 8. Унифицированный процесс разработки

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

    - для разработки новых проектов – унифицированного процесса разработки;

    - для сопровождения – использование инкрементального процесса.

    2.4 Оптимизация процессов разработки и сопровождения

    При переходе к проектному управлению необходима реорганизация бизнес-процессов в соответствии с жизненным циклом реализации проектов. Жизненный цикл проекта – это комбинация процессов и подпроцессов, необходимых для создания (реализации) объекта или решения. Так, жизненный цикл проекта в стандарте PMI (ProjectManagementInstitute, США) состоит из следующих фаз:

    - начальная фаза (инициирование проекта);

    - разработка;

    - реализация;

    - завершение.

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

    Фазы могут обладать следующими характеристиками:

    - границы;

    - вход, выход;

    - длительность;

    - операции;

    - участники;

    - бюджеты.

    Проблематика управления проектами в современном менеджменте подробно разработана и доведена до стандартов. В стандартах проектного управления PMI жизненный цикл проекта разбивается на следующие типовые этапы:

    - процесс инициирования – принятие решения о начале выполнения проекта;

    - процесс планирования – определение целей и критериев успеха проекта и разработка рабочих схем их достижения;

    - процесс исполнения – координация людей и других ресурсов для выполнения плана;

    - процесс анализа – определение соответствия плана исполнения проекта поставленным целям и критериям и принятие решения о корректирующих воздействиях;

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

    Процессы управления проектами приведены на рисунке 9.


    Рисунок 9. Процессы управления проектами

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

    - границы;

    - документы на входе, документы на выходе;

    - временной регламент;

    - операции;

    - участники.

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

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

    - ведение систематизированного реестра проектов, позиционирование проектов по классификаторам реестра, задание типологии основных групп проектов;

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

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

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

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

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

    - бюджетирование проектов, включение бюджета проектов в основной бюджет компании.

    В рамках данной работы рассматриваются две группы процессов:

    - проекты по разработке новых прикладных систем;

    - проекты по сопровождению существующих систем.

    Первая группа проектов полностью соответствует общепринятому пониманию термина «проект», т.к. в результате производится уникальный продукт – новая прикладная система, которая в дальнейшем может пойти в массовое распространение, внедрение и сопровождение.

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

    3.Результаты и рекомендации

    3.1 Описание бизнес-процессов «как должно быть

    Жизненный цикл нового проекта представлен на диаграмме деятельности (Рисунок 10).

    Рисунок10. Жизненный цикл нового проекта

    Создание Устава проекта

    Устав проекта – официальный письменный документ, который формально признает и подтверждает факт существования проекта. Создание Устава проекта позволяет достичь следующих целей:

    - официальное подтверждение начала реализации проекта;

    - выделение проектных ресурсов;

    - обеспечение единства целей;

    - назначение руководителя проекта;

    - изложение общего содержания и целей проекта;

    - определение масштаба проекта и количества итераций.

    Документы на входе:

    - имеющаяся исходная документация по проекту (контракт, постановка задачи, общее описание и пр.).

    Документы на выходе:

    - Устав проекта.

    Временной регламент:

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

    Операции:

    - определение общего содержания проекта;

    - определение целей и задач проекта;

    - определение требований;

    - коммерческое обоснование;

    - оценка затрат и ресурсов;

    - определение функций и обязанностей.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Определение плана итераций

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

    Документы на входе:

    - Устав проекта.

    Документы на выходе:

    - План итераций.

    Временной регламент:

    - 1-5 дней.

    Операции:

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

    - определение результатов каждой итерации.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Планирование итерации

    Итерации планируются последовательно, в каждый момент времени известен план текущей итерации. При высокой степени определенности проекта возможно планирование текущей и следующей итераций. Для каждой итерации определяются проводимые стадии и сроки их завершения. Следует учесть, что желательно на разработку выделить около 1/6 общей длительности итерации, наиболее длительная стадия – проектирование.

    Документы на входе:

    - Устав проекта;

    - План итераций.

    Документы на выходе:

    - План следующей итерации.

    Временной регламент:

    - 1-5 дней.

    Операции:

    - определение выполняемых стадий (анализ, проектирование, реализация, тестирование);

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

    - определение ресурсов и ответственных.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Планирование каждой стадии

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

    Документы на входе:

    - План текущей итерации;

    - Результаты предыдущей итерации;

    - Результаты предыдущей стадии.

    Документы на выходе:

    - План текущей стадии.

    Временной регламент:

    - 1-2 дня.

    Операции:

    - декомпозиция стадии на задачи;

    - определение сроков завершения каждой задачи;

    - определение ресурсов и ответственных.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Выполнение каждой стадии

    Выполнение каждой стадии происходит параллельно с планированием следующей стадии (при ее наличии).

    Документы на входе:

    - План текущей стадии.

    Документы на выходе:

    - для стадии анализа:

    o постановка задачи (ТЗ и пр.) (образец документа приведен в Приложении 1);

    o тестовый пример (образец документа приведен в Приложении 1);

    - для стадии проектирования:

    o технический проект (образец документа приведен в Приложении 1);

    - для стадии реализации:

    o описание реализации (образец документа приведен в Приложении 1);

    o краткое руководство (образец документа приведен в Приложении 1);

    - для стадии тестирования:

    o отчет о тестировании (образец документа приведен в Приложении 1);

    o ведомость замечаний (образец документа приведен в Приложении 1);

    o отчет об устранении замечаний (образец документа приведен в Приложении 1).

    Временной регламент:

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

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

    Операции:

    - выполнение задачи;

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

    Участники:

    - руководитель проекта;

    - исполнители задач.

    Контроль исполнения

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

    Документы на входе:

    - Устав проекта;

    - План итераций;

    - План текущей итерации;

    - План текущей стадии;

    - Результаты выполнения задач:

    o постановка задачи;

    o тестовый пример;

    o технический проект;

    o описание реализации;

    o краткое руководство;

    o отчет о тестировании;

    o ведомость замечаний;

    o отчет об устранении замечаний.

    Документы на выходе:

    - Устав проекта;

    - План итераций;

    - План текущей итерации;

    - План текущей стадии.

    Временной регламент:

    - контроль исполнения должен производиться постоянно по завершении стадий итераций, а также с заданной периодичностью в течение всего хода проекта.

    Операции:

    - контроль сроков;

    - контроль качества результатов;

    - перераспределение ресурсов;

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

    - внесение изменений в Устав проекта;

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

    Участники:

    - руководитель проекта;

    - исполнители задач.

    Завершение проекта

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

    Документы на входе:

    - полный объем проектной документации.

    Документы на выходе:

    - архив проектных документов;

    - замечания и предложения по проекту.

    Временной регламент:

    - 5-10 дней; также зависит от сроков окончательных расчетов.

    Операции:

    - финальные процедуры контроля проекта;

    - закрытие контрактов, проведение расчетов;

    - формирование замечаний и предложений по проекту;

    - архивирование проектной документации.

    Участники:

    - руководитель проекта;

    - проектная группа и прочие заинтересованные лица.


    Проекты по сопровождению

    Жизненный цикл проекта по сопровождению представлен на диаграмме деятельности (Рисунок 11) с указанием входной и выходной информации и ролей пользователей.

    Рисунок11. Жизненный цикл проекта по сопровождению

    Создание Устава проекта

    Документы на входе:

    - имеющаяся исходная документация по проекту (контракт, условия обслуживания, соглашения и пр.).

    Документы на выходе:

    - Устав проекта.

    Временной регламент:

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

    Операции:

    - определение общего содержания проекта;

    - определение целей и задач проекта;

    - определение порядка сопровождения;

    - определение плана выпуска обновлений их объема;

    - коммерческое обоснование;

    - оценка затрат и ресурсов;

    - определение функций и обязанностей.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Определение плана выпуска обновлений

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

    Документы на входе:

    - Устав проекта.

    Документы на выходе:

    - План выпуска обновлений.

    Временной регламент:

    - 1-2 дня.

    Операции:

    - определение сроков выпуска обновлений;

    - определение объема обновлений.

    Участники:

    - руководитель проекта;

    - заинтересованные лица.

    Планирование итерации

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

    В каждый момент времени известен подробный план текущей итерации. По мере поступления заявок происходит планирование следующих итераций. Для каждой итерации определяются проводимые стадии и сроки их завершения.

    Документы на входе:

    - План выпуска обновлений;

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

    Документы на выходе:

    - План итерации.

    Временной регламент:

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

    Операции:

    - рассмотрение заявки;

    - включение заявки в план;

    - декомпозиция плана на задачи;

    - определение сроков завершения каждой задачи;

    - определение ресурсов и ответственных.

    Участники:

    - руководитель проекта.

    Выполнение итерации

    Выполнение итерации происходит параллельно с планированием следующей итерации (при ее наличии).

    Документы на разработка программного обеспечения на примере дипломная работа План текущей итерации.

    Документы на выходе:

    - для стадии анализа:

    o заявка (образец документа приведен в Приложении 1);

    o тестовый пример (образец документа приведен в Приложении 1);

    - для стадии проектирования:

    o технический проект;

    - для стадии реализации:

    o описание реализации (образец документа приведен в Приложении 1);

    o краткое руководство (образец документа приведен в Приложении 1);

    - для стадии тестирования:

    o отчет о тестировании (образец документа приведен в Приложении 1);

    o ведомость замечаний (образец документа приведен в Приложении 1);

    o отчет об устранении замечаний (образец документа приведен в Приложении 1);

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

    o отчет об установке обновления/программного обеспечения (образец документа приведен в Приложении 1);

    o ведомость разработка программного обеспечения на примере дипломная работа (образец документа приведен в Приложении 1).

    Временной регламент:

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

    Операции:

    - выполнение задачи;

    - подготовка и согласование результирующих документов;

    - переход на следующую стадию.

    Участники:

    - руководитель проекта;

    - исполнители задач.

    Контроль исполнения

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

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

    Общий и детализированный план должен быть доступен всем заинтересованным лицам.

    Документы на входе:

    - Устав проекта;

    - План выпуска обновлений;

    - Планы итераций;

    - Результаты выполнения задач:

    o заявка;

    o тестовый пример;

    o технический проект;

    o описание реализации;

    o краткое руководство;

    o отчет о тестировании;

    o ведомость замечаний;

    o отчет об устранении замечаний;

    o отчет об установке обновления/программного обеспечения;

    o ведомость обучения.

    Документы на выходе:

    - Устав проекта;

    - План выпуска обновлений;

    - Планы итераций.

    Временной разработка программного обеспечения на примере дипломная работа контроль исполнения должен производиться постоянно по завершении стадий итераций, а также с заданной периодичностью в течение всего хода проекта.

    Операции:

    - контроль сроков;

    - контроль качества результатов;

    - перераспределение ресурсов;

    - внесение изменений в планы;

    - внесение изменений в Разработка программного обеспечения на примере дипломная работа проекта;

    - подготовка и согласование результирующих документов.

    Участники:

    - руководитель проекта;

    - исполнители задач.

    Завершение проекта

    Документы на входе:

    - полный объем проектной документации.

    Документы на выходе:

    - архив проектных документов;

    - замечания и предложения по проекту.

    Временной регламент:

    - 5-10 дней; также зависит от сроков окончательных расчетов.

    Операции:

    - финальные процедуры контроля проекта;

    - закрытие контрактов, проведение расчетов;

    - формирование замечаний и предложений по проекту;

    - архивирование проектной документации.

    Участники:

    - руководитель проекта;

    - проектная группа и прочие заинтересованные лица.

    Управление ходом проекта

    Процесс перехода между стадиями

    В процессе перехода продукта с одной стадии на другую в рамках текущей итерации, как правило, происходит тесное взаимодействие между исполнителями этих стадий (Рисунок 12).

    Рисунок12. Взаимодействие между исполнителями стадий

    В то время, пока стадии «перекрываются» (зеленая зона на рисунке), это взаимодействие является необходимым для того, чтобы исполнители следующей стадии получили ответы на все возникающие вопросы.

    Однако, если взаимодействие продолжается и после завершения предыдущей стадии (оранжевая зона на рисунке), это уже может свидетельствовать о низком дипломные работы по охране окружающей среды результатов предыдущей стадии либо о недостаточной разработка программного обеспечения на примере дипломная работа исполнителей текущей стадии.

    Если взаимодействие продолжается и после того, как начинается еще одна стадия (красная зона на рисунке), это приводит к существенному увеличению сроков разработки и к серьезному снижению качества продукта, т.к. изменения вносятся практически непрерывно – в постановку задачи, в проектную документацию, в код приложения.

    Наиболее серьезная проблема – когда на стадии разработки необходимо внесение изменений на обоих предыдущих этапах – анализ и проектирование. Это, как правило, приводит к существенному увеличению сроков получения результата.

    Для упорядочивания процесса разработки продуктов предлагается следующий порядок:

    Каждая стадия должна перекрываться во времени с предыдущей, в этот промежуток передаются разработка программного обеспечения на примере дипломная работа предыдущей стадии.

    Взаимодействие в оранжевой зоне по вопросам изменения результатов предыдущей стадии необходимо сводить к минимуму и по возможности переносить на следующие итерации. Если это невозможно (в случае критически важных изменений), необходимо пересматривать план проекта. Все факты взаимодействия должны фиксироваться документально.

    Взаимодействие в красной зоне должно происходить только с уведомлением руководителя проекта об обнаруженных вопросах, фиксироваться документально и приводить к пересмотру плана проекта.

    Взаимодействие в черной зоне необходимо категорически запретить и перенести на следующую итерацию, т.к. в это время должны быть завершены уже обе стадии, и должна выполняться следующая стадия. Например, если во время стадии «Реализация» начинается взаимодействие между аналитиками и проектировщиками (в рамках текущей итерации), происходит изменение постановки задачи, как следствие – необходимо отразить изменения в проектных документах и в уже реализованных частях продукта, что приводит к значительному увеличению сроков реализации и падению качества.

    Документирование процесса перехода между стадиями

    Для каждой стадии должны быть определены результирующие документы для передачи продукта на следующую стадию (Рисунок 13). В этом случае процесс передачи и последующего взаимодействия будет дипломная работа на тему планирование проекта, управляемым и отслеживаемым.

    Рисунок13. Документирование процесса перехода между стадиями

    Если у исполнителей следующей стадии есть замечания к результатам предыдущей стадии, они обязательно оформляются документально в виде ведомости замечаний и передаются лицу, ответственному за предыдущую стадию. Исправление замечаний может выполняться на этой же итерации (приводит к сдвигу сроков либо сокращению объемов работ следующих стадий данной итерации), либо может быть перенесено на следующую итерацию (следует проверить необходимость сдвига сроков в общем плане итераций).

    Исправления, вносимые по результатам замечаний, также должны оформляться документально в виде протокола устранения замечаний.

    Если исправления вносятся на текущей стадии:

    - увеличивается срок предыдущей стадии в связи с необходимостью исправления замечаний;

    - возможно, увеличивается срок текущей стадии (в связи с изменением объема работ, в связи с необходимостью ожидания исправлений).

    Образцы и краткое содержание документов, указанных на рисунке, приведены в Приложении 1.

    Процесс перехода между итерациями

    После завершения каждой итерации должен обеспечиваться выпуск очередной версии продукта с определенным объемом функциональности. Достигнутый объем функциональности определяется в соответствии с выполненными работами из первоначального плана.

    В результате завершения итерации в хранилище данных по проекту, доступном всем заинтересованным лицам, должны находиться следующие данные:

    - пронумерованная версия продукта (библиотеки, исполняемые файлы, база данных и пр.);

    - описание функциональности, добавленной по сравнению с предыдущей версией;

    - пронумерованные версии всех проектных документов на момент завершения итерации.

    Желательно обеспечить сбор статистических данных по количеству взаимодействий на различных стадиях итерации и в различных зонах для последующей оценки результатов.

    Процесс перехода продукта из разработки во внедрение и сопровождение

    При передаче продукта из разработки во внедрение и дальнейшее сопровождение руководитель проекта (при его отсутствии – руководитель подразделения, ответственного за внедрение) составляет план внутренней приемки продукта, в котором должны быть отражены следующие этапы:

    - ознакомление с проектной документацией;

    - демонстрация программного продукта;

    - обучение сотрудников внедрения работе с продуктом.

    Все замечания к продукту, выявленные на данных этапах, классифицируются, и либо устраняются путем проведения еще одной итерации доработки продукта, либо включаются в план разработки следующей версии продукта.

    Оценка деятельности

    Качество продукта, выпускаемого после каждой стадии, приблизительно можно определить после завершения итерации по собранным статистическим данным.

    Большое количество документов «Уведомление об изменении требований» разработка программного обеспечения на примере дипломная работа о недостаточной проработке соответствующих вопросов во время выполнения стадии, и, соответственно, о низком качестве работы исполнителей.

    Документ «Ведомость замечаний» свидетельствует о наличии вопросов и замечаний со стороны исполнителей какой-либо стадии к результатам предыдущей стадии. Чаще всего это также свидетельствует о низком качестве результатов, реже – о недостаточной квалификации исполнителей текущей стадии.

    Влияние данных документов на конечный результат можно оценить с помощью зоны, в которую попадали документы: зеленая зона – незначительное влияние, оранжевая зона – среднее влияние, красная зона – значительное влияние, черная зона – очень серьезное влияние.

    Данные документы должны строго отслеживаться руководителем проекта и руководителями соответствующих структурных подразделений для оперативного определения проблемных участков проекта.

    3.2 Изменения в организационно-штатной структуре

    Изменения в организационно-штатной структуре представлены на рисунке 14.

    Для обеспечения перехода к проектному управлению необходимо осуществить изменения в организационно-штатной структуре. Ключевым изменением является выделение руководителей проекта, непосредственно подчиняющихся генеральному директору/заместителю генерального директора, что позволит постепенно осуществлять переход к проектно-ориентированной структуре разработка программного обеспечения на примере дипломная работа. Ресурсы для каждого проекта должны подбираться из соответствующих структурных подразделений под контролем линейных разработка программного обеспечения на примере дипломная работа, однако после выделения ресурса на проект основным руководителем становится руководитель проекта – до момента окончания участия данного сотрудника в проекте. После этого сотрудник возвращается в пул доступных ресурсов в рамках своего подразделения.

    В целях организации качественного процесса анализа необходимо выделение Аналитического департамента, в разработка программного обеспечения на примере дипломная работа которого включается как Аналитический отдел, так и Отдел документационного обеспечения.

    Все структурные подразделения, занимающиеся разработкой, объединяются в Центр разработки. В том числе выделяется Управление развития инструментальных средств и Управление разработки прикладных систем. Первое подразделение занимается инструментарием для разработка программного обеспечения на примере дипломная работа прикладных систем, второе же – непосредственно разработкой прикладных систем. В состав Центра также входит Управление проектирования.

    Все разработка программного обеспечения на примере дипломная работа, ответственные за внедрение и сопровождение, объединяются в Департамент сопровождения.

    В состав Департамента системной интеграции включены подразделения, ответственные за техническую поддержку, ИТ-инфраструктуру, дизайн и рекламу.

    Также отдельно выделен Департамент профессионального развития персонала.

    Рисунок 14. Новая организационно-штатная структура

    3.3 Регламентирование деятельности

    Наиболее проблемные и неформализованные бизнес-процессы были регламентированы с целью максимально точного дипломная работа контрольная работа реферат доклад действий сотрудников компании оптимизированным бизнес-процессам.

    Регламентированию подверглись в первую очередь следующие процессы:

    - Оперативный мониторинг информационная поддержка хода исполнения контрактных обязательств (Регламент приведен в Приложении 2);

    - Разработка программного обеспечения и выпуск дистрибутивов (Регламент приведен в Приложении 3);

    - Исполнение заявок на обслуживание и сопровождение (Регламент приведен в Приложении 4).

    Регламенты являются определяющими документами при выполнении указанных процессов.

    Помимо регламентов, были разработаны типовые должностные инструкции (образец приведен в Приложении 5), а также квалификационные требования к сотрудникам компании (образец приведен в Приложении 6), что позволит упорядочить и организовать процессы, связанные с движением кадров в компании.

    3.4 Перспективные направления автоматизации

    В ходе анализа деятельности компании выявлен ряд направлений, перспективных с точки зрения последующей автоматизации. Так как компания сама является разработчиком программного обеспечения и заинтересована в разработке комплексных решений по управлению предприятием, оптимальным решением будет разработка собственной системы.

    Приоритетными являются нижеуказанные направления.

    Информационная поддержка исполнения контрактных обязательств:

    - учетные сведения о клиентах;

    - реестр контрактов;

    - документационное обеспечение контрактных обязательств (контракты, дополнительные соглашения, календарные планы, акты, счета, отчеты и прочая документация).

    Кадровый учет:

    - штатная структура компании;

    - личные карточки сотрудников;

    - приказы о назначении, увольнении, отпусках и пр.;

    - табельный учет.

    Делопроизводство и документооборот:

    - входящая исходящая корреспонденция;

    - создание, согласование и утверждение внутренней документации;

    - поддержка управления версиями документов.

    Информационная поддержка процессов выпуска дистрибутивов и обновлений:

    - учет дистрибутивов и стадий их выпуска;

    - учет замечаний, реализованных в дистрибутиве;

    - учет разовых обновлений;

    - учет установленных у клиентов версий дистрибутивов.

    Информационная поддержка процессов разработки, разработка программного обеспечения на примере дипломная работа, сопровождения, технической поддержки:

    - планирование деятельности;

    - учет и отслеживание хода выполнения задач и заявок пользователей, оперативных поручений руководства.


    Заключение

    Поставленная задача оптимизации бизнес-процессов была решена в полном объеме; оптимизации подверглись основные процессы деятельности организации, а именно разработка, внедрение и сопровождение программного обеспечения.

    Осуществлен переход от функционально-ориентированной к проектно-ориентированной штатной структуре компании.

    В результате анализа наиболее удобным типом процесса разработки для новых проектов признан унифицированный процесс, для проектов по сопровождению – инкрементальный процесс.

    Выработан и регламентирован стандарт планирования и управления жизненным циклом проектов, в том числе процессы перехода между стадиями итерациями в ходе проектов.

    Разработаны регламенты ключевых процессов: разработки, сопровождения, контроля.

    Сформирован комплект образцов документации, создаваемой во время жизненного цикла проекта.

    Выработан ряд решений по управлению кадрами, в том числе должностные инструкции и квалификационные требования, решения по мотивации персонала и совершенствованию системы оплаты труда.

    Определен ряд направлений, перспективных для последующей комплексной автоматизации с помощью системы управления предприятием.

    Список использованной литературы

    1.Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. СПб.: Питер, 2005.

    2.Бек К. Экстремальное программирование. СПб.: Питер, 2002.

    3.Браудэ Э. Технология разработки программного обеспечения. СПб.: Питер, 2004.

    4.Даешь инжиниринг! М.: Издательство Эксмо, 2005.

    5.Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.

    6.Крачтен, Филипп. Введение в Rational Unified Process. 2-е изд. М.: Издательский дом «Вильямс», 2002.

    7.Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP. М.: КУДИЦ-ОБРАЗ, 2004.

    8.Липунцов Ю.П. Управление процессами. Методы управления предприятием с использованием информационных технологий. М.: Компания АйТи, 2003.

    9.Хэлдман Ким. Управление проектами. М.: ДМК Пресс; Академия АйТи, 2007.

    Приложение 1

    Образцы внутренних документов

    Структура документа «Постановка задачи»

    Данный документ является уточняющим для документа «Техническое задание», составляется по каждой значимой функциональности и содержит более подробные описания бизнес-процессов, в т.ч. в нотации UML.

    1. Основные сведения

    - Название проекта, модуль

    - Название функциональности

    - Основания для разработки (контракт, пользователь, законодательство, и пр.)

    - Необходимость распространения на другие проекты

    2. Описание назначения

    - Описание функциональности, ссылки на законодательство и пр.

    3. Варианты использования

    a. Название варианта использования, текстовое описание, UML-схема

    b. Название варианта использования, текстовое описание, UML-схема

    c. …

    4. Диаграммы потоков данных

    при необходимости

    5. Диаграммы переходов состояний

    при необходимости

    6. Диаграммы классов

    при необходимости

    7. Проект пользовательского интерфейса

    8. Ограничения

    требования к аппаратному обеспечению, производительности и пр.

    Структура документа «Заявка»

    1. Основные сведения

    - Номер заявки (из внутренней системы)

    - Название проекта, модуль

    - Основания для разработки

    2. Описание заявки

    - Текстовое описание содержания заявки, при необходимости – ссылки на скриншоты (для ошибок – обязательно)

    3. Скриншоты

    - копии экранов с выделенными и пронумерованными блоками (для ссылок в текстовом описании)

    Структура документа «Тестовый пример»

    1. Основные сведения

    - Номер разработка программного обеспечения на примере дипломная работа (из внутренней системы)

    - Название проекта, модуль

    - Название функциональности

    2. Тестовые примеры

    a. Тест 1

    o Входные параметры: «название» = «значение»

    o Последовательность действий пользователя

    o Выходные параметры: «название» = «значение»

    b. Тест 2

    o Входные параметры: «название» = «значение»

    o Последовательность действий пользователя

    o Выходные параметры: «название» = «значение»

    c. …

    Структура документа «Описание реализации»

    1. Основные сведения

    - Номер заявки (из внутренней системы) – в случае выполнения разовой заявки

    - Название проекта, модуль

    - Название функциональности

    2. Описание алгоритма

    - Общее описание выбранных методов решения задачи

    3. Реализация вариантов использования (если были указаны в «Постановке задачи»)

    a. Название варианта использования, алгоритм реализации

    b. …

    4. Описание системных изменений

    a. перечень измененных системных объектов (процедур, функций, модулей разработка программного обеспечения на примере дипломная работа пр.), при этом в коде указанных объектов обязательны следующие комментарии:

    o дата создания, автор, назначение;

    o все входные и выходные параметры, а также используемые внутри переменные должны иметь описание назначения;

    o код должен быть разбит на логические блоки (при их наличии), снабженные комментариями об их назначении;

    o при каждом изменении в начале после описания назначения должен вставляться комментарий с датой, автором и описанием изменения.

    b. видимо, в основном для ИИС – перечень измененных классов, гридов, и пр.

    5. Описание интерфейсных изменений

    при изменении форм – скриншоты «что было» - «что стало» с выделением изменений

    при добавлении форм – скриншоты этих форм

    6. Диаграммы классов

    при необходимости, видимо, в основном для ИИС

    Структура документа «Краткое руководство»

    Документ «Краткое руководство» составляется в свободном стиле, при этом он должен отражать описание всех вариантов использования, реализованных для требования.

    Структура документа «Отчет о тестировании»

    Данный документ составляется на основании «Программы и методики испытаний» либо «Тестового примера».

    1. Основные сведения

    - Номер заявки (из внутренней системы) – в случае выполнения разовой заявки

    - Название проекта, модуль

    - Название функциональности

    - Дата тестирования, номер цикла тестирования

    - Суммарные данные (% успешно пройденных тестов)

    2. Тест 1: пройден/не пройден

    - Должно быть:

    o Входные параметры: «название» = «значение»

    o Последовательность действий пользователя

    o Выходные параметры: «название» = «значение»

    - Получено:

    o Выходные параметры: «название» = «значение»

    - Комментарии

    3. Тест 2: пройден/не пройден

    - …

    4. …

    Структура документа «Ведомость замечаний»

    «Ведомость замечаний» составляется в двух случаях:

    1. При проведении внутреннего тестирования на основании «Отчета о тестировании» составляется перечень замечаний, в который включаются все не пройденные тесты, а также дополнительно обнаруженные в ходе тестирования ошибки.

    2. При внедрении и сопровождении системы.

    Структура документа является следующей:

    1. Основные сведения

    - Название проекта

    - Дата составления, последовательный номер, автор

    - Ссылка на «Отчет о тестировании» либо период внедрения/сопровождения, за который получены указанные замечания

    2. Таблица замечаний

    № п/пЗамечаниеКомментарии
    формулировка замечаниядополнительная информация, ссылка на скриншоты

    3. Скриншоты

    - копии экранов с выделенными и пронумерованными блоками (для ссылок в комментариях)

    Структура документа «Отчет об устранении замечаний»

    1. Основные сведения

    - Номер заявки (из внутренней системы) – в случае выполнения разовой заявки

    - Название проекта, модуль

    - Название функциональности

    - Дата составления, последовательный номер

    2. Таблица замечаний

    № п/пЗамечаниеДата устраненияКомментарии
    формулировка замечания

    Структура документа «Отчет об установке»

    1. Основные сведения

    - Номер обновления/дистрибутива (из внутренней системы)

    - Название организации

    - Дата установки, ФИО сотрудника, проводившего установку

    - При установке у пользователя – ФИО пользователя, должность, комната, телефон

    2. Сведения об ошибках в ходе установки

    - допустимо использование скриншотов

    Структура документа «Ведомость обучения»

    1. Основные сведения

    - Название организации, проекта

    - ФИО сотрудника, проводившего обучение

    2. Ведомость обучения

    № п/пФИО, должность пользователяДата обученияИзученные разделыПодпись пользователя

    Приложение 2

    Регламент оперативного мониторинга информационной поддержки хода исполнения контрактных обязательств

    1.Общие положения

    1.1. Данный документ описывает порядок сбора, обработки и хранения информации о контрактных обязательствах, а также регламент оперативного мониторинга хода исполнения контрактных обязательств ответственными исполнителями и руководителями.

    1.2. Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).

    2.Ответственность и состав информации

    2.1. Бухгалтерия организации является ответственной за ввод следующих данных:

    - адресные данные юридических лиц;

    - банковские реквизиты юридических лиц;

    - дипломная работа тему материнский семейный капитал о подготовке счетов, счетов-фактур;

    - сведения о поступлении оплаты по счетам.

    2.2. Помощник генерального директора является ответственным за ввод следующих сведений:

    - проекты контрактов и этапы в составе данных контрактов;

    - сведения о порядке и сроках оплаты этапов контрактов;

    - документы к контракту;

    - сведения об отправке и получении отчетных документов по этапам работ.

    2.3. Руководитель департамента/управления (либо заместитель руководителя) является ответственным за ввод следующих сведений:

    - содержание работ по этапам контрактов (для последующего планирования работ начальником отдела).

    2.4. Начальник отдела является ответственным за:

    - планирование работ по этапам контрактов;

    - контроль хода исполнения этапов;

    - формирование отчета о ходе исполнения контрактных обязательств.

    3.Регламент учета данных

    3.1. Начальник отдела (либо по его распоряжению – заместитель начальника отдела) разработка программного обеспечения на примере дипломная работа за 15 дней (если не указано иное) до окончания срока этапа обеспечить разработка программного обеспечения на примере дипломная работа отчет о ходе исполнения этапа с перечислением всех работ, проводившихся в рамках данного этапа.

    3.2. Помощник генерального директора обязан за 15 дней (если не указано иное) до окончания срока этапа подготовить акт по данному этапу контракта.

    3.3. Бухгалтер обязан за 15 дней (если не указано иное) до окончания срока этапа подготовить счет на оплату работ по данному этапу контракта.

    3.4. Отчет, акт и счет на оплату работ прикрепляются к исходящему письму, регистрируются делопроизводителем и отправляются заказчику. В системе при этом автоматически отражаются сведения о сроках отправки документов.

    3.5. При возврате документов делопроизводитель отмечает срок подписания и возврата документов.

    3.6. При поступлении оплаты бухгалтерия отмечает срок поступления оплаты. В системе автоматически отражаются сведения о закрытии соответствующего этапа.

    4.Регламент оперативного мониторинга

    4.1. Ежедневно заместитель руководителя департамента и начальник отдела (либо по его распоряжению – заместитель начальника отдела) контролирует перечень активных задач по контрактным обязательствам и обеспечивает их оперативное выполнение.

    4.2. Еженедельно заместитель руководителя департамента и начальник отдела (либо по его распоряжению – заместитель начальника отдела) контролирует перечень этапов, по которым наступили сроки подготовки отчета о выполненных работах и при необходимости готовит либо дает поручение о подготовке указанных отчетов.

    4.3. Еженедельно заместитель руководителя департамента, помощник генерального директора и бухгалтер контролирует перечень этапов, по которым наступили сроки подготовки акта и счета на оплату работ. При наступлении сроков подготовки документов:

    4.3.1. Помощник генерального директора готовит акт о выполненных работах;

    4.3.2. Начальник отдела (либо по его указанию – заместитель начальника отдела), ответственного за выполнение данных работ, готовит отчет о проделанных работах;

    4.3.3. Бухгалтер готовит счет на оплату работ.

    4.4. После отправки документов помощник генерального директора еженедельно контролирует сроки подписания и возврата документов.

    4.5. После возврата документов бухгалтер ежедневно контролирует поступление оплаты по подписанным счетам.


    Приложение 3

    Регламент разработки программного обеспечения и выпуска дистрибутивов

    1.Общие положения

    1.1. Данный документ описывает внутренний порядок разработки программного обеспечения и выпуска дистрибутивов для установки у заказчиков.

    1.2. Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).

    2.Основные участники регламента

    2.1. Основными участниками данного регламента являются:

    - руководитель проекта;

    - ответственные руководители структурных подразделений;

    - аналитик;

    - разработчик;

    - специалист по тестированию;

    - технический писатель.

    3.Регламент регистрации заявки

    3.1. Руководитель проекта обязан обеспечить регистрацию в системе всех заявок на разработку по соответствующим проектам.

    3.2. При регистрации заявки руководитель проекта обязан обеспечить ввод следующих сведений:

    - проект;

    - реализация в рамках проекта;

    - организация;

    - в рамках какого этапа контракта выполняется работа;

    - содержание работы;

    - плановые сроки выполнения работы;

    - срочность Заказчика;

    - приоритет работы;

    - вид базы данных (SQL, ORACLE, SQL+ORACLE);

    - приложить постановку задачи и все возможные документы, связанные с постановкой задачи.

    3.3. При сохранении заявки система должна обеспечить автоматическое присвоение номера заявки.

    3.4. Руководитель проекта также должен иметь возможность классификации ранее введенной в разработка программного обеспечения на примере дипломная работа заявки на обслуживание в качестве заявки на разработку. При этом должны быть заполнены поля, указанные в п.3.2 настоящего Регламента, а также следующие поля:

    - пример базы данных;

    - шаги воспроизведения.

    3.5. Для инициирования процесса обработки заявки руководитель проекта должен:

    - перевести задачу на исполнение аналитикам;

    - при отсутствии необходимости проведения анализа (например, в случае обнаружения очевидных ошибок разработчика) перевести задачу на исполнение разработчикам.

    Источник: https://domashke.net/referati/referaty-po-menedzhmentu/diplomnaya-rabota-modelirovanie-biznes-processov-na-primere-kompanii-razrabotchika-programmnogo-obespecheniya

    06.07.2017 Юдин С. Д. Курсовые 5 Comments
    5 comments
    1. По моему мнению Вы не правы. Могу отстоять свою позицию. Пишите мне в PM, обсудим.

    2. Охотно принимаю. На мой взгляд, это интересный вопрос, буду принимать участие в обсуждении.

    Добавить комментарий

    Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>