Место моделирования в проектировании больших программных систем. Моделируемые аспекты программных систем

 

 

10. Проектирование программных систем. Главный программист, его задачи и функции

Проектирование:

• в большей степени связано с искусством;
• программа наследует все проблемы реальной системы;
• при проектировании даётся обоснование как ПО, так и ТС;
• проектирование - это итерационный процесс;
• проектированием может заниматься не каждый.

Методология следующая:

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

Уровни проектирования:

• Верхний уровень

• разделение на подсистемы, модули;
• определение взаимодействия;
• реализации замкнутости подсистем.

• Средний уровень

• реализация технических решений;
• выделение макрослоёв;
• проектирование модулей;
• определение потоков данных.

• Нижний уровень

• кодирование программ;
• технологии кодирования;
• структурное программирование.

Главный программист:

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

 

11. Тестирование программ. Тестирование модулей. Тестирование скомпонованной программы.

Тестирование и верификация:

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

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

1. Тестирование элементов – индивидуальная проверка каждого модуля. Для обнаружения ошибок в рамках модуля тестируются его важнейшие управляющие пути. Тестирование элементов обычно рассматривается как дополнение к этапу кодирования. Оно начинается после разработки текста модуля.
2. Тестирование интеграции – тестирование сборки модулей в программную систему.
3. Тестирование правильности – проверить реализацию в программной системе всех функциональных и поведенческих требований, а также требования эффективности.
4. Системное тестирование – проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализации всех системных функций. В конечном счете системные тесты должны проверять, что все системные элементы правильно объединены и выполняют назначенные функции.

1. Тестирование восстановления

2. Тестирование безопасности
3. Стрессовое тестирование
4. Тестирование производительности

 

12. Управление разработкой программ. Управление сроками. Управление кадрами. Управление организационной структурой.

Руководство разработкой:

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

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

• Идея(замысел)
• Разработка
• Набор исполнителей
• Выполнение проекта
• Завершение проекта

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

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

Работа с кадрами состоит  из следующих элементов:

• оценки потребностей и определения критериев подбора кадров;
• подбора кадров и приема на работу;
• обучения кадров;
• руководства кадрами (организационной структурой);
• оценки качества работы персонала.

 

13. Управление разработкой программ. Значение внутренних стандартов. Документирование разработки.

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

Управление разработкой программ:

1. Спецификация требований

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

3. Сроки реализации

4. Расстановка кадров

5. Бюджет

6. Документирование рабочих стандартов

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

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

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

Документирование разработки:

• Требования формулируются совместно заказчиком и проектировщиком с максимально возможной строгостью
• Язык формулировок требований должен быть понятен пользователю и проектировщику
• Нужно документировать требования
• Если требования не записаны и не сделаны доступными разработчикам, они вроде бы и не существуют

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

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

 

14. Методы интеграции информационных систем. Интеграция однородных и разнородных систем.

Интеграция данных и знаний в  большинстве случаев основана на трех методах:

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

2) федерализация данных – обеспечивает  единую виртуальную картину одного  или нескольких первичных файлов  данных;

3) распространение данных –  осуществляют копирование данных  из одного места в другое.

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

Как правило, на предприятиях используются информационные системы следующих  направлений:

1. Системы бухгалтерского и налогового учета

2. Системы управления предприятием

3. Системы документооборота

4. CRM-системы

5. Системы управления специфичными процессами

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

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

Интеграция обеспечивает:

• Исключение двойного ввода информации и дублирования действий

• Надежность и непротиворечивость информации в системе учета

• Оперативность получения необходимой управленческой информации

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

• Повышение управляемости процессами

• Повышение прозрачности бизнес-процессов для собственников и руководителей

 

15. Методы интеграции информационных систем. Сервис ориентированная архитектура

Интеграция данных и знаний в  большинстве случаев основана на трех методах:

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

2) федерализация данных – обеспечивает  единую виртуальную картину одного  или нескольких первичных файлов  данных;

3) распространение данных –  осуществляют копирование данных  из одного места в другое.

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

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

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

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

Принципы:

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