Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях экономики.
Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:
• сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
• наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);
• отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
• необходимость интеграции существующих и вновь разрабатываемых приложений;
• функционирование в неоднородной среде на нескольких аппаратных платформах;
• разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
• существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима.
Ручная разработка обычно порождала следующие проблемы:
• неадекватная спецификация требований;
• неспособность обнаруживать ошибки в проектных решениях;
• низкое качество документации, снижающее эксплуатационные качества;
• затяжной цикл и неудовлетворительные результаты тестирования.
С другой стороны, разработчики ИС исторически всегда стояли последними в ряду тех, кто использовал компьютерные технологии для повышения качества, надежности и производительности в своей собственной работе (феномен "сапожника без сапог").
Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
Появлению CASE-технологии и CASE-средств предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как: • подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования; • широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования; • внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.
CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ. Технология проектирования определяется как совокупность трех составляющих:
• пошаговой процедуры, определяющей последовательность технологических операций проектирования;
• критериев и правил, используемых для оценки результатов выполнения технологических операций;
• нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
• небольшую команду программистов (от 2 до 10 человек);
• короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
• повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
• фаза анализа и планирования требований;
• фаза проектирования;
• фаза построения;
• фаза внедрения.
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);
• DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь"
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги.
При выполнении Вашего заказа будут использованы современные технологии разработки и проектирования. Разработанные программные продукты отличает удобный и продуманный интерфейс, широкий набор функций, надежная работа. Осуществляется пострение функциональной модели (IDEF0) предметной области, диаграмм потоков данных (DFD), логической и физической моделей данных.
Для начала выполнения работ заказчику необходимо составить техническое задание (ТЗ), согласно ГОСТ 34.602-90 Информационная технология. Техническое задание на создание автоматизированной системы, в котором должны быть обязательно перечислены следующие разделы ТЗ:
• общие сведения;
• назначение и цели создания (развития) системы;
• характеристика объектов автоматизации;
• требования к системе;
• состав и содержание работ по практическому созданию системы:
••• на каком языке программирования должна быть напсана программа и в какой среде разработки программ (например на Delphi в визуальной среде разработки программ CodeGear RAD Studio 2009);
••• какой тип баз данных необходимо применять (например MS Access, InterBase, MS SQL);
••• связь с какими дополнительными программами должна поддерживать создаваемая система (например с программами пакета MS Office такими как Word, Excel или с CAD-программами, такими как Autodesk AutoCAD, Autodesk Inventor);
• порядок контроля и приемки системы;
• требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
• требования к документированию;
• источники разработки.
В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы - допускается вводить дополнительные, исключать или объединять разделы ТЗ.
Так как написание практических студенческих курсовых или дипломных работ по Автоматизированным системам это довольно объемная задача, требуящая значительного количества времени и соответствующей стоимости.
Тип работы | Срок выполнения, кол. раб. дней | Цена, грн | ||
Практическая часть: | ||||
база данных | 10 | от 500 | ||
основная программа (управляющая базой данных) | 10 | от 500 | ||
Теоретическая часть: | ||||
пояснительная записка | 10 | от 10 грн./стр. |
В таблице указан нормальный срок выполнения, если же у Вас срочная работа - тогда цена такой работы увеличивается пропорционально сокращению срока (например если необходимо выполнить в 2 или 3 раза быстрее, тогда соответственно и стоимость увеличится в 2 или 3 раза).
В таблице приведены усреднённые цены на работы.
Пример №1.
Дипломная работа на тему: «Проектирование информационной подсистемы библиотеки» [6,1 Mb] Файл PDF.
«Архив с практической частью (программрой и базой данных)» [3,6 Мb] Файл RAR.
Содержание:
Введение 4
Техническое задание 7
Назначение разработки 7
Требования к программе 8
Требования к программной документации 11
1. Анализ исходных данных 12
1.1 Описание предметной области 12
2. Специальная часть. Выбор средств/методологии проектирования 16
2.1 Сравнительные характеристики СУБД 16
2.2 Выбор СУБД 22
2.3 Сравнительные характеристики языков программирования 24
2.4 Выбор среды и языка программирования для реализации системы 29
2.5 Построение инфологической (концептуальной) модели предметной области 32
2.6 Проектирование логической структуры базы данных 38
2.7 Проектирование физической структуры базы данных 39
2.8 Создание датологической модели базы данных 46
2.9 Алгоритмизация приложения 48
2.10 Программирование, создание приложения 51
3. Экспериментальная часть 59
3.1 Объект испытаний 59
3.2 Цель испытаний 59
3.3 Перечень документов, предъявляемых на испытании 59
3.4 Объем испытаний 60
3.5 Методика проведения проверки комплектности программной документации 64
3.6 Методика проверки выполнения основных функций системы 67
4. Технологическая часть 79
4.1. Назначение программы 79
4.2. Условия выполнения программы 81
4.3. Требования к персоналу (пользователю) 82
4.4. Выполнение программы 83
5. Экономическая часть 104
5.1 Расчет экономической эффективности программного обеспечения 104
5.2. Выводы по экономической эффективности создания программного обеспечения 114
6. Охрана труда и окружающей среды 115
6.1 Обеспечение условий труда на рабочем месте библиотекаря 115
6.2. Анализ состояния охраны труда в помещении 117
6.3. Анализ вентиляции, искусственного и природного освещения 118
6.4. Мероприятия по обеспечению благоприятных условий труда 127
6.5. Микроклимат рабочей зоны 128
6.6. Выводы 129
Выводы 130
Список использованной литературы: 132
Пример №2.
Курсовая работа на тему: «Написание программы на языке программирования Delphi по "Расчету и автоматическому вычерчиванию сверла в AutoCad"» [2 Mb] Файл RAR.
Функциональное назначение: Система автоматизированного проектирования сверл предназначена для ввода исходных данных, расчета сверла, сохранения результатов расчета в базе данных и автоматического вычерчивания рабочего чертежа сверла в программе AutoCAD.
Содержание:
Введение 3
1. Анализ характеристик существующих систем 5
1.1 Анализ основных задач систем автоматизированного проектирования 6
1.2 Описание существующей системы автоматизированного проектирования AutoCad 12
2. Задачи проектируемой автоматизированной системы 17
2.1 Формирование основных требований к программе 17
2.2 Определение целей и задач автоматизированного проектирования 19
2.3 Основные функции и задачи, решаемые системой 20
3. Проектирование системы 21
3.1 Выбор средств/методологии проектирования 21
3.2 Определение архитектуры программного средства 25
3.3 Определение входных и выходных данных 25
3.4 Алгоритмизация проектируемой системы 25
4. Реализация, создание приложения 28
4.1 Создание интерфейса 28
4.2 Создание базы данных 31
4.3 Создание вычислительной среды системы 37
4.4 Создание Lisp – программы 45
5. Тестирование программного средства 54
Заключение 57
Список использованной литературы: 58
1. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем [965 Kb] Фаил PDF.
Целью данного обзора является введение в особенности современных методов и средств проектирования информационных систем, основанных на использовании CASE-технологии. Читатель должен получить возможность принятия обоснованного, а не волевого решения относительно использования этих технологий. Приводимые в обзоре рекомендации могут способствовать успешному внедрению CASE-средств и уменьшить риск неправильных инвестиций. Несмотря на высокие потенциальные возможности CASE-технологии (увеличение производительности труда, улучшение качества программных продуктов, поддержка унифицированного и согласованного стиля работы) далеко не все разработчики информационных систем, использующие CASE-средства, достигают ожидаемых результатов. Существуют различные причины возможных неудач, но, видимо, основной причиной является неадекватное понимание сути программирования информационных систем и применения CASE-средств. Необходимо понимать, что процесс проектирования и разработки информационной системы на основе CASE-технологии не может быть подобен процессу приготовления пищи по поваренной книге. Всегда следует быть готовым к новым трудностям, связанным с освоением новой технологии, последовательно преодолевать эти трудности и последовательно добиваться нужных результатов. Обзор предназначен для начинающих и опытных разработчиков информационных систем, для руководителей проектов и системных аналитиков.