Экзамен - Вопросы и ответы, страница 4

7. Требования к программным модулям при проведении декомпозиции.

1. Проблемы модулей

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

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

• модули взаимодействуют посредством совместно используемых или общих данных самым неожиданным образом.

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

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

• линейная структура;

• ветвление из входной точки ветвями в итоге в одну выходную;

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

3. Характеристики модуля

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

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

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

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

• сцепление по общей области - избегать его всеми силами;

• сцепление по по управлению;

• сцепление по формату;

• сцепление по содержимому - по общим константам;

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

4. Хороший программный модуль

• Сложность взаимодействия модуля с другими модулями должна быть меньше сложности его внутренней структуры

• Хороший модуль снаружи проще, чем внутри

• Хороший модуль проще использовать, чем построить

8. Роль абстракции в процессе проектирования. Барьер абстракции. Абстракции сущности и абстракции поведения.

Абстракция:

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

• разделяет смысл и реализацию объекта;

• выделение существенных особенностей объекта и отделения их от несущественных - барьер абстракции.

Виды абстракций:

• абстракция сущности – объект представляет собой полезную модель некой сущности в предметной области.

• абстракция поведения – объект состоит из обобщенного множества операций.

• абстракция виртуальной машины – объект группирует операции, которые либо вместе используются более высоким уровнем управления, либо сами используют некоторый набор операций более низкого уровня

• произвольная абстракция – объект включает в себя набор операций, не имеющих друг с другом ничего общего

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

9. Уровень реализации. Критерии выбора языка программирования и стандартов программирования.

Уровень реализации включает:

• Выбор языка программирования

• Выбор стандартов программирования

• Выбор инструментария программирования

• Проектирование диалогового взаимодействия

• Уровни квалификации. Главный программист

• Компоновка программ

• Контроль версий системы

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

• парадигма языка программирования;

• вид типизации;

• компилируемость или интерпретируемость кода;

• управление памятью;

• стандартизация;

• переносимость кода;

• скорость разработки;

• скорость исполнения;

• количество потребляемой памяти.

Сложность языка не всегда напрямую связана с его мощностью.

Концепция языка программирования неотрывно связана с его реализацией. Для того чтобы компиляция одной и той же программы различными компиляторами всегда давала одинаковый результат, разрабатываются стандарты языков программирования. Существует ряд организаций, целенаправленно занимающихся вопросами стандартизации. Это Американский национальный институт стандартов ANSI (American National Standards Institute), Институт инженеров по электротехнике и электронике IEEE (Institute of Electrical and Electronic Engineers), Организация международных стандартов ISO (International Organization for Standardization). Как правило, при создании языка выпускается частный стандарт, определяемый разработчиками языка.

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

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

• в большей степени связано с искусством;

• программа наследует все проблемы реальной системы;

• при проектировании даётся обоснование как ПО, так и ТС;

• проектирование - это итерационный процесс;

• проектированием может заниматься не каждый.

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

• разбиение на уровни абстракций: от самых крупных, важных вещей в проекте к самым мелким;

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

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

• должны определяться как данные, так и операции над ними.

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

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

• разделение на подсистемы, модули;

• определение взаимодействия;

• реализации замкнутости подсистем.

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

• реализация технических решений;

• выделение макрослоёв;

• проектирование модулей;

• определение потоков данных.

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

• кодирование программ;

• технологии кодирования;

• структурное программирование.

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

• обеспечивает создание и эффективное функционирование отдела;

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

• несет ответственность за эксплуатацию и развитие АИС в части системного и прикладного ПО;

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

• изучение рынка программных средств.

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

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

• верификация с начала разработки;

• проведение инспекций кодов программ;

• тестирование отдельных модулей;

• тестирование скомпонованной программы;

• планирование тестирования проводится одновременно с началом работ.

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

1. Тестирование элементов – индивидуальная проверка каждого модуля. Для обнаружения ошибок в рамках модуля тестируются его важнейшие управляющие пути. Тестирование элементов обычно рассматривается как дополнение к этапу кодирования. Оно начинается после разработки текста модуля.

2. Тестирование интеграции – тестирование сборки модулей в программную систему.

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

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

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

2. Тестирование безопасности

3. Стрессовое тестирование

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

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

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

• спецификация требований - составление ТЗ;

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

• сроки реализации;

• расстановка кадров;

• бюджет;

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

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

• Идея(замысел)

• Разработка

• Набор исполнителей

• Выполнение проекта

• Завершение проекта

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

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

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

• оценки потребностей и определения критериев подбора кадров;

• подбора кадров и приема на работу;

• обучения кадров;

• руководства кадрами (организационной структурой);

• оценки качества работы персонала.

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

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

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

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

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

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

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

5. Бюджет

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

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

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

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

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

• являются передовыми и многообещающими.

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

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

• Язык формулировок требований должен быть понятен пользователю и проектировщику

• Нужно документировать требования

• Если требования не записаны и не сделаны доступными разработчикам, они вроде бы и не существуют

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

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

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

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