Ускорить в офисе работу.
Согласование документов
Удобней будет многократно,
Когда за каждым из акцептов
Шагать на край Земли не надо.
Классификация по масштабу
Персональная ИС, Автоматизированное рабочее место (АРМ)
Для обособленных задач бывает уместно
Автоматизированное рабочее место
По сути, программа для одного человека
Без ролей и синхронизаций бывает, при этом.
Групповая ИС
Для коллективного владения
Набором данных применяют
Системы для подразделения
Их групповыми называют.
Корпоративная ИС, система планирования ресурсов предприятия (ERP)
Система для учета многих,
А, в идеале, всех ресурсов
На предприятии позволит
Убрать ненужную нагрузку
На повторение процесса
Учета общих данных. Силой
Их актуальность обеспечит
И согласованность в единой
Корпоративной базе данных.
Центральное ядро системы
С набором дополнений разных
Бизнес-процессов и отделов
Собой совместно представляют
Систему ERP (Еэрпэ́). Не спешно
Ей все процессы закрывают,
Когда внедрение успешно.
Система интерактивной аналитической обработки (OLAP)
OLAP (ОЛА́П)-системы позволяют
Наборы данных обработать,
По многим измерениям сразу
Собрав суммарные отчеты.
Система управления эффективностью организации (BPM)
Дополнив ERP ОЛАП-ом,
Получим BPM (Бэпээ́м)-систему.
Взяв в ERP наборы данных,
ОЛАП позволит быстро сделать
Их обработку: выявление
И поиск узких мест в процессах,
И способов их улучшения,
Для повсеместного прогресса.
Глава 3. Жизненный цикл систем
Жизненный цикл представляет
Набор этапов описание,
В коих система пребывает
За всё своё существование.
С момента зарождения мысли
О появлении системы
До вывода её из жизни
Всё размещают в эти схемы.
Распространённые этапы
В жизненном цикле для программы:
Анализ, разработка плана,
Концепции и тех. задания,
Реализация проекта,
Отладка и объединение,
Ввод в эксплуатацию, не редко
Сопровождение, завершение.
Модель жизненного цикла
Модели жизненного цикла
Описывают ряд процессов,
Их связи и порядок в «жизни»
Систем для большего прогресса
При их создании и развитии.
Известны разные модели,
Рассмотрим виды основные,
Что чаще можно встретить в деле.
Каскадная модель ЖЦ
Каскадные модели часто
Используют для тех процессов,
Где выполнение понятно
И не предвидится эксцессов.
Реализацию системы
В такой модели представляют
В виде простой линейной схемы
Всё по порядку выполняют.
Она проста и для показа
Заказчикам понятна, в общем.
Но, если не учесть всё сразу,
Затраты резко станут больше.
Спиральная модель ЖЦ
Начав с простого прототипа,
Спиральная модель позволит
Заказчика довольно быстро
Спросить, насколько всё устроит.
И снизит риск проблем в заказе
Того, что может быть не нужно,
За счёт такой обратной связи.
Но есть и минус перегружен
Процесс создания системы
Может стать, если будет много
Документации и, в целом,
Возможно растяжение сроков.
Гибкая методология разработки (Agile)
Agile (Аджа́йл) группа направлений
Набор подходов и методик
Для разработки приложений,
Который, в общем, нынче в моде.
В Agile разработку кода
Проводят в несколько подходов
По две иль три недели, чтобы
Сформировать на каждом что-то.
И по итогу каждой «сдачи»
Продемонстрировать программу
И скорректировать задачи.
Итак, процесс идёт кругами.
Документации здесь мало.
С заказчиком общения много,
Что в планах риски понижало.
Рабочий код всему итогом.
Среди методик Scrum (Скра́м) известен
И много прочих, чьи находки,
Основаны на манифесте
Гибкой программной разработки.
Быстрая разработка приложений (Rapid application development, RAD)
RAD(Рад)-разработка получила
Широкое распространение,
Поскольку быстроту сулила
При разработке и внедрении.
И позволяла экономить
Бюджет и время. Предлагая
Минимизировать, где можно,
Усилия. Предоставляя
Полученные результаты
Заказчику для регулярной
Обратной связи на этапе
Любом, чтоб уточнять задания.
1
Адаптивная разработка ПО (Adaptive Software Development, ASD)
При адаптивной разработке
Есть три этапа для повтора:
Обдумывание в подготовке
И выявлении набора
Потребностей и назначения;
Взаимодействие чтоб вместе
С заказчиком принять решение;
И обучение здесь тесты,
Анализ и обзор работы
Дают возможность извлечения
Полезных каждому уроков,
Для непрерывных улучшений.
Экстремальное программирование (Extreme Programming, XP)
При экстремальной разработке
Традиционные подходы
Для сроков более коротких
На уровень выходят новый.
Заказчик рядом для вопросов,
Все пишем максимально просто,
Проверка кода парный кодинг,
Тесты написаны до кода,
Релизы частые как можно,
Рефакторинг все время тоже,
Владение кодом будет общим,
Стандарт единый и не сложный.
Глава 4. Исследование предметной области
Предметная область
Предметная область
Часть реального мира
Объекты, чьи свойства
С отношениями в силе
Будем мы изучить
Для любых операций
Для познания и
Для автоматизаций.
Проект
Проект особый вид работы,
Из не циклических этапов.
Он ограниченный во многом:
По времени и по затратам.
С ограничением ресурсов,
Не повторяется, обычно,
И потому ему план нужен
Чтоб выполнение шло прилично.
А если проект не пошёл?
Как ни крути, а сделать сразу
Проект получится не всякий.
И остаётся лишь к показу
Представить прототип двоякий.
Потом решить, что делать дальше,
Улучшить или же подправить
В итоге, позже или раньше,
Его куда подальше сплавить.
Начинать или продолжать?
О, сколько можно начинать?
Пора бы завершить хоть что-то.
Ещё есть способ передать
Кому-то третьему работу
Как где-то «слышано» не раз:
Два основных движенья в силе:
Один держать, что есть сейчас,
Другой менять устройство в мире.
Когда закончится проект
Процесс начнётся при удаче,
Но вот поддерживать «эффект»
Уже других людей задача.
Гештальт
Финализировать проект,
Отрезав целостный участок,
Так чтобы не было к нему
Ведущих в памяти путей.
Весьма существенный аспект
Для эффективности, и часто
Для жизни, судя по всему.
Чтоб, в целом, было веселей.
Когда проектов очень много
И тянутся из года в год,
Когда не видно их итога,
И результат не настаёт,
Гештальт открытый дольше срока,
Как потемневший небосвод,
Нависший тучей у порога,
Свою погоду создаёт.
Итак, какой-то из финалов
Даёт надежду нам в пути,
На то, что много или мало,
Но можем далее идти.
Без суматохи и авралов
Итог спокойно подвести
Полезно, чтобы легче стало
Работать далее в АйТи.
Бизнес-процесс
Бизнес-процесс совокупность работ
И задач всех, что продукт создаёт
Или услугу для потребления
Есть на три группы подразделение:
Управляющие определяют
Кто как системами управляет.
Операционные основная работа,
Она приносит в итоге доходы.
Поддерживающие процессы те,
Что обслуживают другие системы все.
Бизнес-логика
Бизнес-логика это
Группа принципов, правил,
Поведения объектов
Всё то, что составит
В разработке предметную
Область решения
Воплощение конкретное
И ограничения.
Способы изучения предметной области
Есть много способов различных,
Для получения знаний о
Бизнес-процессах и типичных
Их протеканиях. Итого:
Интервьюирование
Интервьюирование метод
Прямой и эффективный, он
Даёт возможность нам изведать
Всю информацию, при том,
Что будем спрашивать системно,
Записывая без помех
«Предметку», или постепенно
Брать информацию у всех.
Рабочий семинар
Рабочий семинар, пожалуй,
Быть может эффективным самым
Вариантом получения знаний,
Однако сложен и затратен.
Анкетирование
Для массового сбора данных
И группового мнения можно
Использовать анкеты. Брать их
Бумажно или электронно
Документация
Для изучения процессов,
Весьма полезно получить
Документацию, при этом,
Внимание стоит обратить
На все входные-выходные
Формы, уставы, положения,
Регламенты и должностные
Инструкции всё в рассмотрение.
Обзор аналогов
Для подготовки к разработке
Необходимо изучение,
Обзор аналогов насколько
Уже готовые решения
Задачу выполняют может,
Их применение дешевле,
Чем будет разработка новой
Системы, или совершенней.
Для изучения вариантов
Аналогов системы стоит,
Вначале перечень составить
Из требований, что устроит
Заказчика по всем аспектам.
Найти системы, что подходят,
Вооружившись интернетом.
В табличном виде их оформить,
И указать какие будут
Покрыты требования ими,
Поставив минусы и плюсы
В таблице, где их разместили.
Глава 5. Структурное моделирование
Декомпозиция
Декомпозиция нужна,
Для изучения системы.
Ее использование нам
Даёт систему постепенно
Делить на части до тех пор,
Пока любая из частей
Не станет ясной на обзор,
Позволив разобраться в ней.
Нотации моделирования
Есть много всяческих нотаций
Для построения диаграмм,
Чтоб можно было собираться
Как разработчикам программ,
Так и заказчикам, и прочим
Участникам и «налегке»
Всем разъясняться на рабочем
Одном наглядном языке.
IDEF (Integrated DEFinition)
Методологии семейства
IDEF (Айде́ф) дают создать модели
Систем, предоставляя средства
Различных видов построения.
IDEF0 (Айдее́ф ноль) этап начальный
Анализа систем их функций.
На этом виде диаграммы
Есть ряд известных всем конструкций.
Процессы функции системы,
Потоки данных: управления
Обычно сверху от процессов,
Выходы справа, входы слева.
Такая форма представления
Бизнес-процессов позволяет
Показывать их отношения
Соподчиненность отражая.
Диаграммы потоков данных (Data flow diagrams, DFD)
Один из нескольких подходов
Для изучения систем
Их функций и границ народу
Известный многим, хоть не всем
Подход структурный и системный
На основании DFD (Дээфдэ́).
С разбором функций постепенным
Для составления ТЗ.
Начальный уровень контекстный
На нем есть основной процесс
С потоками взаимодействий
С внешними сущностями. Здесь
Определяются границы
Для построения системы
По документам и страницам
Взаимодействующим с нею.
В дальнейшем изучении будем
Декомпозировать процесс мы
На подпроцессы список функций
Для изучаемой системы.
Элементы DFD-диаграмм
Для построения моделей
Потоков данных применяют
Нотации. Для этих целей
В них элементы выделяют:
Процесс указывают смело
Для отражения функций, целей,
Обозначают, что ей делать
Как в целом также и отдельно.
Внешняя сущность для показа
Объектов вне нашей системы
И демонстрации их связи
С системным основным процессом.
Хранилище оно же база
Тех данных, что хранят в системе.
Его располагают сразу
На первом уровне модели.
Поток графическое средство
Показа связей диаграммы:
От внешней сущности к процессу
И от процесса к базе данных.
Словарь данных
Словарик данных помогает
Потокам данных описания
Сформировать. Предоставляет
Их в виде текстового знания.
Так, чтобы было всем понятно,
Что именно передаётся
Между процессов. Аккуратно
В итоге всё в БД сведётся.
Спецификация процессов
Для описания процессов,
Когда нет смысла в их делении,
Бывает применить полезно
Другие средства в объяснении:
Спецификации, к примеру,
Как описание в виде текста,
Да хоть обычную блок-схему,
Иль флоу-форму всё уместно.
Глава 6. Объектно-ориентированное моделирование
Унифицированный язык моделирования (Unified Modeling Language, UML)
Для построения диаграмм
В унифицированном виде
При описании программ
Язык объектный примените
Универсальный UML (Юмээ́л).
В нём моделируйте процессы
Программных и бизнес-систем
В разных разрезах и контекстах.
Виды диаграмм UML
2
Диаграмма классов (Class diagram)
Статическая диаграмма
Структуры кода и системы
Пожалуй, диаграмма классов,
Одна из главных в Юмээле.
На ней показывают классы,
Их методы и атрибуты.
И связи между ними сразу
Здесь тоже есть в их общей сути.
Диаграмма прецедентов (Use case diagram)
На диаграмме прецедентов
Показывают отношения
Связи от юзеров системы
К ее вариантам выполнения.
Диаграмма последовательности (Sequence diagram)
Взаимодействие объектов
Показывают диаграммой
Последовательности выполнения.
На ней представлены программа
И пользователь, и другие
Участники, как вертикали.
И сообщения между ними
По времени их протекания.
Диаграмма компонентов (Component diagram)
На диаграмме компонентов
Показаны библиотеки,
Модули, файлы и пакеты
И связи между ними всеми.
Диаграмма развёртывания/размещения (Deployment diagram)
На диаграмме размещения
Показывают наложение
Программного обеспечения
На аппаратные решения.
Глава 7. Техническая документация
Техническое задание3
Для выполнения проекта
С известным качеством и сроком
Весьма полезным документом
ТЗ является. Во многом
Его задача однозначность
При понимании системы.
В ТЗ описаны задачи
Проекта так, чтоб были всеми
Они восприняты в едином
Ключе и смысле, и трактовок
Различных не было в картине
И описании разработок.
Частное техническое задание
Когда проект большой ведётся,
И разработчиков в нём много,
На подсистемы создаётся
Задание частное в итоге.
Технический проект4
Все описания дальнейших
Проектных принятых решений
Технический проект содержит,
В нём излагают о системе
Устройство, алгоритмы, схемы,
От базы данных до внедрения
И эффективности системы.
На языке для исполнения:
Когда ТЗ для всех понятно,
ТП уже для программиста
В нём не столь нужно деликатно
Искоренять все жаргонизмы.
Руководство пользователя
Когда написана система,
Для помощи в работе с нею
Полезна текстовая схема,
Чтоб описать её идею
Для пользователей и просто
Помочь в процессе изучения
Её работы руководство.
Обычно в нем обозначение
Дается следующим вопросам:
Обзор и ссылки, назначение
Системы, функции и способ
Их применения, и решение
Проблем возможных при работе
И при типичном применении.
Полезный документ для многих,
При изучении приложения.
Руководство администратора
Администратору в работе
Инструкция нужна другая
В ней описание даёте
Как доступ, роли назначают,
Как заполняют базы данных
И разворачивают сервер,
Как исправлять ошибки надо,
Коль есть известные примерно.
Программа и методика испытаний5
Когда проект идёт к внедрению,
Бывает нужен документ,
В котором есть определение,
Как «тестить» каждый элемент.
Программа тестов-испытаний
При разработке под заказ
Даёт возможность понимания,
Что как проверить и, подчас,
Нужна не менее задания
На разработку, ведь по ней
Проводится согласование
С заказчиком системы всей.
В ней нужен список всех условий
Для выполнения работ,
Сценарий, тесты, по которым
Заказчик проверять пойдёт.
Часть 2. Архитектура ПО
Архитектура
Архитектура приложения
Борьба со сложностями в нём.
И без неё, как наваждение,
Затраты потекут ручьём,
Потом безудержным потоком
На проведение небольших,
Казалось бы, работ. Итогом
Перерасход сил трудовых.
Программная архитектура
Есть описание частей
Системы вся её структура,
Устройство, отношения в ней
Все те решения, что в дальнейшем
Затратно будет изменять.
Поэтому вопрос важнейший
Их, в целом, правильно принять.
Хорошая архитектура
Даёт возможность широко
Сопровождения процедуру
Вести удобно и легко.
Вся суть здесь в разделении кода
На модули и компоненты.
С таким предположением, чтобы