 |
Пользовательская документация
|
|
|
|
Пользовательская документация является частью технического проекта и разрабатывается в соответствии с
1. ГОСТ 19.402-2000 ЕСПД. Описание программы. –М; Изд-во стандартов,2001
2. ГОСТ 19.505-79 ЕСПД. Руководство оператора. – М.; Изд-во стандартов, 1982.
3. ГОСТ 19.301-2000 ЕСПД. Программа и методика испытаний. – М.; Изд-во стандартов, 2001.
Необходимо отметить, что помимо документации, современный программный продукт должен иметь систему контекстной помощи, типс-подсказки на элементах управления, эргономичный дизайн, «красивую» упаковку, дизайн СиДи, сайт технической поддержки, логотип, и т.д.
Конечно это в идеале. Но каждый разработчик должен ставить своей целью сделать завершенный проект и учесть все сопутствующие требования рынка. Иначе, мы будем работать «в корзину». Запомните: выбирают по обертке!
– описание программы
– руководство пользователя
– руководство администратора
– программа и методика испытаний
Глава 3. Реализация и тестирование
Обработка ошибок в объектно-ориентированном подходе стала не просто механизмом проверки параметров на недопустимость, а превращена в новую концепцию построения программного кода!
Это обстоятельство позволяет формулировать требование безошибочности функционирования программного обеспечения, которое предполагает не отсутствие ошибок при функционирование ПО, а выстроенную систему обработки ошибок и систему реакций на ошибочные ситуации.
Тестирование системы это процесс, который сопровождает процесс разработки, начиная с самых первых этапов! Ведь ошибки, допущенные проектировщиком, на ранних этапах разработки проекта сложнее всего исправить. Например выбор неподходящей архитектуры, нелогичная система классов.
|
|
|
Большинство фирм, специализирующихся на разработке ПО, придерживаются стратегии по разработке тестирующих алгоритмов параллельно с разработкой основных компонентов ПО. Широко применяются системы трассировки ошибок (bagtracking), такие, например, bagzilla и аналоги.
Итоговое тестирование программного продукта оформляется протоколом. В протоколе линейным списком приводится исчерпывающий список функций и результат тестирования каждой функции.
В данном разделе пояснительной записки могут приводится графики зависимости производительности от нагрузки, от количества процессов, результаты тестирования на утечки оперативной памяти и другие гесты, важные с точки зрения дальнейшей эксплуатации программного обеспечения.
Еще одним важным моментов в 21 веке становится контроль ПО на уязвимости с точки зрения несанкционированного использования, получения доступа к закрытым или защищенным данным, нарушение работоспособности сервера через отдельное приложение. Особенно актуальны данные вопросы для web-приложений, доступным извне для любых, в том числе и деморализованных пользователей.
Поэтому контроль за корректностью вводимых данных (в том числе и защита от sql-инъекций, эксплоитов, переполнений), анализ алгоритмов и построение многоуровневой системы защиты от сбоев ¾ задача каждого инженера программиста.
Заключение
В заключении дается оценка результату работы. Обязательно отмечаются выявленные недостатки проекта, ошибки, обнаруженные при тестировании. Хочу отметить, что даже самые протестированные программные продукты ведут списки обнаруживаемых ошибок и постоянно выпускают патчи обновлений и исправлений. Результаты тестирования могут не порадовать нас характеристиками производительности, что позволяет сформулировать рекомендации по совершенствованию или переработке программы.
|
|
|
Разработчик всегда должен видеть следующий свой шаг, что бы его текущий шаг не оказался последним. Говоря словами английского писателя и мыслителя Оруэлла «Кого не интересует будущее, тому не найдется в нем места».
Правила оформления исходного кода программы
Правила оформления кода являются предметом особого внимания. В каждой компании придерживаются своего корпоративного стиля оформления кода, компания Microsoft предприняла попытку возведения выработанного своего корпоративного стиля в ранг международного стандарта.
Существую программы автоматического форматирования набираемого кода для java сред разработки. Они позволяют настроить форматирование под свой стиль.
Для нас главное – это уяснить, что правильное (единое) оформление кода позволяет организовать процесс коллективной разработки с выполнением принципа повторного использования кода, более эффективно.
Приведем примерный набор правил.
- Исходный код программы должен содержать не менее 30% строк комментариев. Комментариями-шапками снабжаются все классы и структуры по форме:
/* Наименование класса: назначение
Описание
…
*/
class ClassName { …
};
Комментарии присутствуют при определении всех переменных:
int I; // счетчик для организации циклов
Комментарии предшествуют любым условным, циклическим операторам и операторам выбора:
// цикл по всем книгам хранилища
for (int j = 0; j < booksCount; j++) { …
- Имена переменных должны начинаться с прописной латинской буквы, имя должно отражать семантику переменной, составное имя является конкатенацией слов, заглавные буквы второго и всех последующих слов в которой являются прописными:
int phoneNumber; // номер телефона
- Имена классов должны начинаться с прописной латинской буквы, имя должно отражать семантику класса, составное имя является конкатенацией слов, заглавные буквы которых являются прописными:
/*
PrinterAdapter: абстрактный класс для работы с устройством печати.
Наследует интерфейс абстрактного класса Adapter и расширяет его функциональность.
*/
class PrinteAdapter: public Adapter { …
- Имена констант задаются прописными латинскими буквами.
|
|
|
- Все блоки текста выравниваются по границе табуляции (2 пробела)
|
| // проверка на команду отключения
| if (controlError == CE_SHUTDOWN) {
| |
| | // если код ошибки 10 – не определена
| | if (errorCode == 10) {
| | | codeReset = true;
| | | return false;
| | }
| | }
|
- Все операторы +, -, … и блоки условий, циклов (...) и кода {…} отделяются пробелами:
if ( averageTeperature < 10 ) {
costLevel += pirson * studentDistributionCvantil;
}
пробелы ставятся после всех знаков пунктуации:;,…
for (int j = 0; j < 10; j++) {
- После каждой {, определяющей начало блока кода, и }, определяющей конец блока кода, ставится перевод строки.
- Каждый оператор начинается с новой строки, блок определения переменных отделяется от кода пустой строкой или двумя (сверху и снизу), если объявляется локальная переменная в коде:
src[20] = 0;
char* domainController; // локальная переменная – имя контроллера домена
domainController = new char[20];
strncpy(domainController, src, 20);
…
- Каждой условной конструкции, циклической или выбора предшествует комментарий, отделенный от вышестоящего текста пустой строкой
a = b + 3;
// условие на не превышение средней температуры
// за период 10 градусов
if (averageTeperature < 10) {
studentDistributionCvantil = a * a + (35.148 / (34 + gammaLevel));
costLevel += pirson * studentDistributionCvantil;
}
- Длина строки не должна превышать 90 символов с целью обеспечения возможности распечатки исходного кода на бумажном носителе. Если строка превышает размер в 90 символов, она переносится по оператору или иному разделителю и форматируется на отступ в одну табуляцию от «главной» строки:
studentDistributionCvantil =
chisq(probabilisticLevel * pow(dispersion, 2)) *
a + (35.148 / (34 + gammaLevel));
Конечно, это не исчерпывающий набор правил оформления, это, всего лишь, авторские рекомендации.
|
|
|
