Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


АТЫРАУСКИЙ ИНСТИТУТ НЕФТИ И ГАЗА



МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

РЕСПУБЛИКИ КАЗАХСТАН

АТЫРАУСКИЙ ИНСТИТУТ НЕФТИ И ГАЗА

 

« ТЕХНОЛОГИЧЕСКИЙ» ФАКУЛЬТЕТ

Кафедра «МАТЕРИАЛОВЕДЕНИЕ И ТЕХНОЛОГИЯ НОВЫХ МАТЕРИАЛОВ»

Дисциплина: «Концепция современного естествознания»

Р Е Ф Е Р А Т

На тему: «ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ »

Выполнил студент: Дюсенов М.С.

Группы: АиУ - 08 к/о

Проверила: Дюсекенова Сауле Рафаиловна

Оценка: __________________________

Подпись:   __________________________

  « ___ » _______________20 10г.

                 

                                   

 

Атырау, 2010


ПЛАН

Специфика разработки программных средств.

Специфика разработки программных средств.

Жизненный цикл программного средства.

Понятие качества программного средства.

Обеспечение надежности - основной мотив разработки программных средств.

Методы борьбы со сложностью.

Обеспечение точности перевода.

Преодоление барьера между пользователем и разработчиком.

Контроль принимаемых решений.

1.10. Курс " Принципы разработки программного обеспечения с использованием RUP, эффективных юзкейсов и программного обеспечения IBM Rational Suite"

ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ

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

 

Специфика разработки программных средств.

 

Разработке программных средств присущ ряд специфических особенностей [3.1].

Прежде всего следует отметить некоторое противостояние: неформальный характер требований к ПС (постановки задачи) и понятия ошибки в нем, но формализованный основной объект разработки - программы ПС. Тем самым разработка ПС содержит определенные этапы формализации, а переход от неформального к формальному существенно неформален.

Разработка ПС носит существенно творческий характер (на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение), а не сводится к выполнению какой-либо последовательности регламентированных действий. Тем самым эта разработка ближе к процессу проектирования каких-либо сложных устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до самого ее конца.

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

Продукт разработки имеет и другую специфическую особенность: ПС при своем использовании (эксплуатации) не расходуется и не расходует используемых ресурсов.

 

 

Понятие качества программного средства.

Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода, т.е. обладать определенным качеством. Качество ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей [3.6]. Это не означает, что разные ПС должны обладать одной и той же совокупностью таких свойств в их высшей возможной степени. Этому препятствует тот факт, что повышение качества ПС по одному из таких свойств часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и снижения качества этого ПС по другим его свойствам. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование.

Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС должны быть прежде всего фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС принято считать [3.6-3.10]:

функциональность,

надежность,

легкость применения,

эффективность,

сопровождаемость,

мобильность.

Функциональность - это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.

Надежность подробно обсуждалась в первой лекции.

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

Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

Сопровождаемость - это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.

Мобильность - это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.

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

 

Методы борьбы со сложностью.

Мы уже обсуждали в лекции 2 сущность вопроса борьбы со сложностью при разработке ПС. Известны два общих метода борьбы со сложностью систем:

· обеспечения независимости компонент системы;

· использование в системах иерархических структур.

 

Обеспечение независимости компонент означает разбиение системы на такие части, между которыми должны остаться по возможности меньше связей. Одним из воплощений этого метода является модульное программирование. Использование иерархических структур позволяет локализовать связи между компонентами, допуская их лишь между компонентами, принадлежащими смежным уровням иерархии. Этот метод, по-существу, означает разбиение большой системы на подсистемы, образующих малую систему. Здесь существенно используется способность человека к абстрагированию.

 

 

Обеспечение точности перевода.

Обеспечение точности перевода направлено на достижение однозначности интерпретации документов различными разработчиками, а также пользователями ПС. Это требует придерживаться при переводе определенной дисциплины. Майерс предлагает использовать общую дисциплину решения задач, рассматривая перевод как решение задачи [3.11]. Лучшим руководством по решению задач он считает книгу Пойа " Как решать задачу" [3.12]. В соответствии с этим весь процесс перевода можно разбить на следующие этапы:

· Поймите задачу;

· Составьте план (включая цели и методы решения);

· Выполните план (проверяя правильность каждого шага);

· Проанализируйте полученное решение.

Преодоление барьера между пользователем и разработчиком.

Как обеспечить, чтобы ПС выполняла то, что пользователю разумно ожидать от нее? Для этого необходимо правильно понять, во-первых, чего хочет пользователь, и, во-вторых, его уровень подготовки и окружающую его обстановку. Поэтому следует - привлекать пользователя в процессы принятия решений при разработке ПС, - тщательно освоить особенности его работы (лучше всего - побывать в его " шкуре" ).

 

 

Введение в TestManager

 

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

Рабочий поток (workflow), связанный с использованием TestManager. Основные виды работ (activities) в рамках этого рабочего потока: планирование, проектирование, реализация, исполнение и оценка результатов

Принципы интеграции TestManager с другими инструментами, входящими в IBM Rational Suite. Совместная работа IBM Rational ClearQuest

Организация функционального тестирования (functional testing)

Организация тестирования, связанного с оценкой производительности разрабатываемой системы (performance testing)

 

Введение в SoDA

 

Принципы построения отчетов в SoDA. Возможность извлечения информации из любого продукта, входящего в IBM Rational Suite. Понятие Domain (источник информации)

Организация интерфейса с пользователем. Режимы работы: документ (Document) и отчет (Report). Принцип согласования между документом и источником в режиме Document на основе процесса Intelligent Document Merging

Схема построения шаблона (Template) отчета в SoDA на основе объектно-ориентированного подхода. Команды, используемые для построения Template: OPEN, REPEAT, DISPLAY, LIMIT. Примеры использования

 

Литература.

 

1. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: " ДИАЛОГ-МГУ", 1994.

 

2. М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - С. 11.

 

3. К. Зиглер. Методы проектирования программных систем. - М.: Мир, 1985. - С. 15-23.

 

4. Дж. Фокс. Программное обеспечение и его разработка. - М.: Мир, 1985. - С. 53-67, 125-130.

 

5. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. - P. 5-10.

 

6. Criteria for Evaluation of Software. ISO TC97/SC7 #383.

 

7. Revised version of DP9126 - Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. - Part 6.

 

8. Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. - М.: Мир, 1981. - С. 17-24.

 

9. В.В. Липаев. Качество программного обеспечения. - М.: Финансы и статистика, 1983. - С. 18-30.

 

10. Б. Шнейдерман. Психология программирования. - М.: Радио и связь, 1984. - С. 99-103.

 

11. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 32 - 48.

 

12. Д. Пойа. Как решать задачу. - М.: Наука, 1961.

 

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

РЕСПУБЛИКИ КАЗАХСТАН

АТЫРАУСКИЙ ИНСТИТУТ НЕФТИ И ГАЗА

 

« ТЕХНОЛОГИЧЕСКИЙ» ФАКУЛЬТЕТ


Поделиться:



Последнее изменение этой страницы: 2020-02-16; Просмотров: 108; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.039 с.)
Главная | Случайная страница | Обратная связь