Порядок разработки программного модуля
Пошаговая детализация и понятие о псевдокоде
Контроль программного модуля
Свойства основных конструкций структурного программирования
Завершимость выполнения программы
Принципы и виды отладки
Автономная отладка модуля
Комплексная отладка программного средства
Функциональность и надежность как обязательные критерии качества программного средства
Обеспечение автономности программного средства
Обеспечение легкости применения программного средства
Пользовательская документация программных средств
Назначение аттестации программного средства
Навигация
Обеспечение легкости применения программного средства
Программирование
231244
знака
5
таблиц
6
изображений
12.2.. Обеспечение легкости применения программного средства
П-документированость ПС определяет состав пользовательской документации
В предыдущей лекции было уже рассмотрено обеспечение двух из пяти примитивов качества (устойчивость и защищенность), которые определяют легкость применения ПС.
П-документированность и информативность определяют состав и качество пользовательской документации (см. следующую лекцию).
Коммуникабельность обеспечивается созданием подходящего пользовательского интерфейса и соответствующей реализации исключительных ситуаций. В чем здесь проблема?
12.3. Обеспечение эффективности программного средства.
Эффективность ПС обеспечивается принятием подходящих решений на разных этапах его разработки, начиная с разработки его архитектуры. Особенно сильно на эффективность ПС (особенно по памяти) влияет выбор структуры и представления данных. Но и выбор алгоритмов, используемых в тех или иных программных модулях, а также особенности их реализации (включая выбор языка программирования) может существенно повлиять эффективность ПС. При этом постоянно приходится разрешать противоречие между временной эффективностью и эффективностью по памяти. Поэтому весьма важно, чтобы в спецификации качества было явно указано количественное соотношение между показателями этих примитивов качества или хотя бы заданы количественные границы для одного из этих показателей. И все же разные программные модули по-разному влияют на эффективность ПС в целом: и по вкладу в общие затраты ПС по времени и памяти, и по влиянию на разные примитивы качества (одни модули могут сильно влиять на достижение временной эффективности и практически не влиять на эффективность по памяти, а другие могут существенно влиять на общий расход памяти, не оказывая заметного влияния на время работы ПС). Более того, это влияние (прежде всего в отношении временной эффективности) заранее (до окончания реализации ПС) далеко не всегда можно правильно оценить.
С учетом сказанного, рекомендуется придерживаться следующих принципов для обеспечения эффективности ПС:
сначала нужно разработать надежное ПС, а уж потом добиваться требуемой его эффективности в соответствии со спецификацией качества этого ПС [12.2, 12.3];
для повышения эффективности ПС используйте прежде всего оптимизирующий компилятор - это может обеспечить требуемую эффективность [12.3];
если достигнутая эффективность ПС не удовлетворяет спецификации его качества, то найдите самые критические модули с точки зрения требуемой эффективности ПС (в случае временнoй эффективности для этого потребуется получить распределение по модулям времени работы ПС путем соответствующих измерений во время выполнения ПС); эти модули и попытайтесь оптимизировать в первую очередь путем их ручной переделки [12.3];
не занимайтесь оптимизацией модуля, если этого не требуется для достижения требуемой эффективности ПС.
12.4. Обеспечение сопровождаемости.
С-документированность, информативность и понятность определяют состав и качество документации по сопровождению (см. следующую лекцию). Кроме того, относительно текстов программ (модулей) можно сделать следующие рекомендации.
используйте в тексте модуля комментарии, проясняющие и объясняющие особенности принимаемых решений; по-возможности, включайте комментарии (хотя бы в краткой форме) на самой ранней стадии разработки текста модуля [12.3];
используйте осмысленные (мнемонические) и устойчиво различимые имена (оптимальная длина имени - 4-12 литер, цифры - в конце), не используйте сходные имена и ключевые слова [12.2, 12.3];
соблюдайте осторожность в использовании констант (уникальная константа должна иметь единственное вхождение в текст модуля: при ее объявлении или, в крайнем случае, при инициализации переменной в качестве константы [12.2]);
не бойтесь использовать не обязательные скобки (скобки обходятся дешевле, чем ошибки [12.3 ];
размещайте не больше одного оператора в строке; для прояснения структуры модуля используйте дополнительные пробелы (отступы) в начале каждой строки [12.2, 12.3];
избегайте трюков, т.е. таких приемов программирования, когда создаются фрагменты модуля, основной эффект которых не очевиден или скрыт (завуалирован), например, побочные эффекты функций [12.2].
Расширяемость обеспечивается созданием подходящего инсталятора.
Структурированность и модульность упрощают как понимание текстов программ, так и их модификацию.
12.5. Обеспечение мобильности.
Литература к лекции 12.
12.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.
12.2. Г.Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 127-154.
12.3. Д.Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. С. 8-44, 117-178.
12.4. Документация пользователя программного обеспечения/Стандарт ANSI/IEEE 1063-1987.
Лекция 13. ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ
13.1. Документация, создаваемая в процессе разработки программных средств.
При разработке ПС создается большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы [13.1]:
Документы управления разработкой ПС.
Документы, входящие в состав ПС.
Документы управления разработкой ПС (process documentation), протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами (managers) - лицами, управляющими разработкой. Эти документы могут быть следующих типов [13.1]:
Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения.
Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами.
Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка данного ПС.
Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС.
Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.
Документы, входящие в состав ПС (product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами) - во всяком случае они должны быть проверены (протестированы) на соответствие программам ПС. Эти документы образуют два комплекта с разным назначением:
Пользовательская документация ПС (П-документация).
Документация по сопровождению ПС (С-документация).
Похожие работы
... . Объясните, для чего служат разрешения и привилегии в Windows NT. Зав. кафедрой -------------------------------------------------- Экзаменационный билет по предмету СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ Билет № 22 Перечислите возможности и инструменты системы программирования Microsoft Developer Studio. Укажите для чего предназначается буфер в системах ввода-вывода, ...
... набор процедур и функций языков программирования Basic и Pascal, позволяют управлять графическим режимом работы экрана, создавать разнооборазные графические изображения и выводить на экран текстовые надписи. ГЛАВА 2. ГРАФИЧЕСКИЕ ВОЗМОЖНОСТИ ЯЗЫКА ПРОГРАММИРОВАНИЯ В КУРСЕ ИНФОРМАТИКИ БАЗОВОЙ ШКОЛЫ (НА ПРИМЕРЕ BASIC И PASCAL) 2.1 Разработка мультимедиа курса «Графические возможности языков ...
... времени на возню с файлами на дисках или ожидание ввода, не смогут продемонстрировать какое-то впечатляющее увеличение скорости. 2. КЛАССИФИКАЦИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ 2.1. Машинно – ориентированные языки Машинно – ориентированные языки – это языки, наборы операторов и изобразительные средства которых существенно зависят от особенностей ЭВМ (внутреннего языка, структуры памяти и ...
... работе в графическом режиме предназначается для обучения студентов младших курсов Санкт-Петербургской государственной Академии аэрокосмического приборостроения навыкам программирования, а именно работе в графическом режиме языка Turbo-Pascal . Для работы с настоящей программой необходимо знание стандарта языка, интегрированной среды и элементарным навыкам работы с персональным компьютером . ...
0 комментариев