10. Проектирование программных
систем. Главный программист, его задачи
и функции
Проектирование:
- в большей степени связано с искусством;
- программа наследует все проблемы реальной
системы;
- при проектировании даётся обоснование
как ПО, так и ТС;
- проектирование - это итерационный процесс;
- проектированием может заниматься не каждый.
Методология следующая:
- разбиение на уровни абстракций: от самых
крупных, важных вещей в проекте к самым
мелким;
- на каждом уровне абстракции 7 или
менее элементов, потому что человек за
раз может держать в голове только 7 вещей;
- ограниченный контекст - только важные элементы:
не надо в один документ писать обо всём
на свете, для каждого аспекта должен быть
свой, отдельный документ;
- должны определяться как данные, так и
операции над ними.
Уровни проектирования:
- разделение на подсистемы, модули;
- определение взаимодействия;
- реализации замкнутости подсистем.
- реализация технических решений;
- выделение макрослоёв;
- проектирование модулей;
- определение потоков данных.
- кодирование программ;
- технологии кодирования;
- структурное программирование.
Главный программист:
- обеспечивает создание и эффективное функционирование отдела;
- на основе анализа задач и возможностей подразделения составляет календарный план работы и определяет направления, формы, методы и сроки его реализации;
- несет ответственность за эксплуатацию и развитие АИС в части системного и прикладного
ПО;
- обеспечение поддержки программных средств, используемых на предприятии;
- изучение рынка программных средств.
11. Тестирование программ. Тестирование
модулей. Тестирование скомпонованной
программы.
Тестирование и верификация:
- верификация с начала разработки;
- проведение инспекций кодов программ;
- тестирование отдельных модулей;
- тестирование скомпонованной программы;
- планирование тестирования проводится одновременно
с началом работ.
Процесс тестирования может быть представлен
в виде разворачивающейся спирали.
- Тестирование элементов – индивидуальная проверка каждого модуля. Для обнаружения ошибок в рамках модуля тестируются его важнейшие управляющие пути. Тестирование элементов обычно
рассматривается как дополнение к этапу
кодирования. Оно начинается после разработки
текста модуля.
- Тестирование интеграции – тестирование сборки модулей в программную систему.
- Тестирование правильности – проверить реализацию в программной системе всех функциональных и поведенческих требований, а также требования эффективности.
- Системное тестирование – проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализации всех системных функций. В конечном счете системные тесты
должны проверять, что все системные элементы
правильно объединены и выполняют назначенные
функции.
- Тестирование восстановления
- Тестирование безопасности
- Стрессовое тестирование
- Тестирование производительности
12. Управление разработкой программ.
Управление сроками. Управление кадрами.
Управление организационной структурой.
Руководство разработкой:
- спецификация требований - составление ТЗ;
- организационная структура;
- сроки реализации;
- расстановка кадров;
- бюджет;
- документирование рабочих стандартов.
Каждый проект, сложный или простой,
большой или маленький, проходит
несколько этапов развития.
- Идея(замысел)
- Разработка
- Набор исполнителей
- Выполнение проекта
- Завершение проекта
Когда начало и завершение проекта
длится не более трех лет это краткосрочный
проект, проекты от трех до пяти лет
– считаются средними, а уже
от пяти лет – долгосрочным.
Для того, что бы понять в какие сроки проект
укладывается, необходимо создать график
исполнения. Если график удовлетворяет
всех участников проекта – можно приступать
к выполнению, иначе необходимо оптимизировать
сроки.
Коллектив – главный ресурс достижения
успеха. Поэтому к подбору персонала необходимо
подойти со всей ответственностью, не
жалея сил и времени.
Работа с кадрами состоит
из следующих элементов:
- оценки потребностей и определения критериев подбора кадров;
- подбора кадров и приема на работу;
- обучения кадров;
- руководства кадрами (организационной структурой);
- оценки качества работы персонала.
13. Управление разработкой программ.
Значение внутренних стандартов. Документирование
разработки.
Это особый вид управления проектами,
в рамках которого происходит планирование,
отслеживание и контроль за проектами
по разработке программного обеспечения.
Ключевым моментом в управлении проектом
по разработке программного обеспечения
является правильный выбор метода разработки.
Управление разработкой программ:
1. Спецификация требований
2. Организационная структура
3. Сроки реализации
4. Расстановка кадров
5. Бюджет
6. Документирование рабочих стандартов
Внутрифирменные (внутрикорпоративные)
стандарты занимают особое место
в классификации стандартов. Это
связано с тем, что они регламентируют
технологические процессы, происходящие
внутри фирмы (например процессы анализа,
кодирования, тестирования), они максимально
конкретны и детализируют уровень мероприятий,
если пользоваться управленческой терминологией.
Внутрифирменные стандарты, как правило,
базируются на применении методик и
технологий, которые:
- зарекомендовали себя лучшим образом в аналогичных проектах;
- получили наибольшее распространение в области разработки программного обеспечения и непосредственно в области, для которой программное
обеспечение создается;
- являются передовыми и многообещающими.
Документирование разработки:
- Требования формулируются совместно заказчиком и проектировщиком с максимально возможной строгостью
- Язык формулировок требований должен быть понятен пользователю
и проектировщику
- Нужно документировать требования
- Если требования не записаны и не сделаны доступными разработчикам, они вроде бы и не существуют
Постоянное документирование должно
составлять неотъемлемую часть каждого
шага программирования. Постановка
задачи, проектные документы, алгоритмы
и программы – все это документы. Внутренняя
документация, включенная непосредственно
в программу, облегчает чтение кода.
При разработке программы создается
большой объем разнообразной
документации. Она необходима как
средство передачи информации между разработчиками
программы, как средство управления разработкой
программы и как средство передачи пользователям
информации, необходимой для применения
и сопровождения программы.
14. Методы интеграции информационных
систем. Интеграция однородных и разнородных
систем.
Интеграция данных и знаний в
большинстве случаев основана на
трех методах:
1) консолидация данных – данные
собираются из нескольких первичных
систем и интегрируются в одно
постоянное место хранения;
2) федерализация данных – обеспечивает
единую виртуальную картину одного
или нескольких первичных файлов
данных;
3) распространение данных –
осуществляют копирование данных
из одного места в другое.
Возможны однородные и неоднородные
системы. В однородном случае системы
состоят из компонентов, разработанных
по одним и тем же стандартам, с использованием
одних и тех же средств, зачастую одними
и теми же разработчиками, что значительно
упрощает их интеграцию в общую модель.
Однако зачастую системы являются разнородными
и проблема интеграции представляет собой
весьма сложную задачу.
Как правило, на предприятиях используются
информационные системы следующих
направлений:
1. Системы бухгалтерского и налогового
учета
2. Системы управления предприятием
3. Системы документооборота
4. CRM-системы
5. Системы управления специфичными процессами
Данные программные продукты (коробочные
или индивидуальные решения) зачастую,
имеют различных разработчиков
и для того, чтобы реализовать
корректную передачу информации между
ними, необходимы специальные разработки.
Интеграция приложений – это
обеспечение взаимодействия независимо
спроектированных систем.
Интеграция обеспечивает:
• Исключение двойного ввода информации
и дублирования действий
• Надежность и непротиворечивость
информации в системе учета
• Оперативность получения необходимой
управленческой информации
• Возможность дистанционно управлять
бизнесом (интеграция удаленных бизнес
-единиц)
• Повышение управляемости процессами
• Повышение прозрачности бизнес-процессов
для собственников и руководителей
15. Методы интеграции информационных
систем. Сервис ориентированная архитектура
Интеграция данных и знаний в
большинстве случаев основана на
трех методах:
1) консолидация данных – данные
собираются из нескольких первичных
систем и интегрируются в одно постоянное
место хранения;
2) федерализация данных – обеспечивает
единую виртуальную картину одного
или нескольких первичных файлов
данных;
3) распространение данных –
осуществляют копирование данных
из одного места в другое.
Сервис-ориентированная архитектура
– модульный подход к разработке программного
обеспечения, основанный на использовании
сервисов (служб) со стандартизированными
интерфейсами. В основе SOA лежат принципы:
- многократного использования функциональных элементов ИТ,
- ликвидации дублирования функциональности в ПО,
- унификации типовых операционных процессов,
- обеспечения перевода операционной модели компании на централизованные процессы и функциональную организацию на основе промышленной платформы интеграции.
Компоненты программы могут
быть распределены по разным узлам
сети, и предлагаются как независимые,
слабо связанные, заменяемые сервисы-приложения.
Преимущества SOA:
- сокращение издержек при разработке приложений, за счёт упорядочивания процесса разработки,
- расширение повторного использования кода,
- независимость от используемых платформ, инструментов, языков разработки,
- повышение масштабируемости создаваемых систем,
- улучшение управляемости создаваемых систем.
Принципы:
- Архитектура, как таковая, не привязана к какой-то определённой
технологии,
- Независимость организации системы от используемой вычислительной платформы (платформ),
- Независимость организации системы от применяемых языков программирования,
- Использование сервисов, независимых от конкретных приложений, с единообразными
интерфейсами доступа к ним,
- Организация сервисов как слабо связанных компонентов для построения
систем