Главная - Литература

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 [263] 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

Результат использования этих методик организации кода таков: когда Оман и Кук попросили группу опытных программистов выполнить одну задачу на сопровождение программы, среднее время выполнения этой задачи в случае программы из 1000 строк составило только около трех четвертей от времени, потребовавшегося для решения той же задачи при традиционной организации исходного кода (Oman and Cook, 1990b). Более того, при сопровождении кода, задокументированного в соответствии с Книжной парадигмой, программисты получили в среднем на 20% более высокие оценки, чем при сопровождении кода, задокументированного традиционным образом. Оман и Кук пришли к выводу, что, обращая внимание на принципы структурирования книг, можно улучшить понятность кода на 10-20%. В исследовании, проведенном в Университете Торонто, были получены похожие результаты (Ваескег and Marcus, 1990).

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

32.6. Стандарты IEEE

Ценными источниками сведений о документации, не относящейся к уровню исходного кода, являются стандарты разработки ПО, принятые Институтом инженеров по электротехнике и электронике (Institute for Electric and Electrical Engineers, IEEE). Стандарты IEEE разрабатываются группами профессионалов и ученых - экспертов в конкретной области. Каждый стандарт содержит резюме описываемой стандартом области и обычно включает обзор документации, уместной для данной области.

В разработке стандартов принимают участие несколько национальных и международных организаций. Ведущая роль в определении стандартов разработки ПО принадлежит группе IEEE. Некоторые стандарты совместно приняты Международной организацией по стандартизации (International Standards Organization, ISO), Альянсом электронной промышленности (Electronic Industries Alliance, EIA) и Международным инженерным консорциумом (International Engineering Consortium, lEC).

Названия стандартов включают номер стандарта, год его принятия и само название. Так, «1ЕЕЕ/Е1А Std 12207-1997, информационные технологии - процессы жизненного цикла ПО» - это стандарт номер 12207.2, принятый в 1997 году IEEE и EIA.

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

Стандартом верхнего уровня является международный стандарт «ISO/IEC Std 12207, Information Technology - Software http:/yc€26.com/3266 Life Cycle Processes», определяющий схему разработки программных проектов и управления ими. В США этот стандарт был принят как «ШЕЕ/ EIA Std 12207, Information Technology-Software Life Cycle Processes».

Стандарты разработки ПО

IEEE std 830-1998 - рекомендуемая методика составления

спецификаций требований к ПО http: cc2e.com/3273



ШЕЕ Std 1233-1998 - руководство по разработке спецификаций требований к системе

IEEE Std 1016-1998 - рекомендуемая методика описания проекта ПО IEEE Std 828-1998 - стандарт планов управления конфигурацией ПО IEEE Std 1063-2001 - стандарт пользовательской документации IEEE Std 1219-1998 - стандарт сопровождения ПО

Стандарты контроля качества ПО

IEEE Std 730-2002 - стандарт планирования контроля ка-ЬПр:/Шыт1Ш чества ПО

IEEE Std 1028-1997 - стандарт обзоров ПО IEEE Std 1008-1987 (R1993) - стандарт блочного тестирования ПО IEEE Std 829-1998 - стандарт документирования тестов ПО IEEE Std 1061-1998 - стандарт методологии метрик качества ПО

Стандарты управления

IEEE Std 1058-1998 - стандарт планов управления проек-тршгыатшт ами разработки ПО

IEEE Std 1074-1997 - стандарт разработки процессов жизненного цикла ПО

IEEE Std 1045-1992 - стандарт метрик продуктивности ПО

IEEE Std 1062-1998 - рекомендуемая методика приобретения ПО

IEEE Std 1540-2001 - стандарт процессов жизненного цикла ПО - управление риском

IEEE Std 1490-1998 - руководство (заимствование стандарта PMI) к своду знаний по управлению проектами (РМВОК)

Обзор стандартов

Обзоры стандартов можно найти в двух источниках, указан-

тммт

IEEE Software Engineering Standards Collection, 2003 Edition. New w.. и л /лплч York, NY: Institute of Electrical and Electronics Engineers (IEEE).

Этот всесторонний труд содержит 40 самых новых стандартов разработки ПО ANSI/IEEE на 2003 год. Каждый стандарт включает план документа, описание каждого компонента плана и обоснование этого компонента. Этот документ включает стандарты планов контроля качества, планов управления конфигурациями, документов тестирования, спецификаций требований, планов верификации и проверки, описаний проектирования, планов управления проектами и пользовательской документации. Данная книга представляет собой квинтэссенцию опыта сотен лучших специалистов в своих областях и была бы выгодным приобретением практически при любой цене. Некоторые из стандартов доступны и отдельно. Все стандарты можно заказать у организа-



ции IEEE Computer Society из города Лос-Аламитос, шт. Калифорния, и на сайте www.computer.org/cspress.

Moore, James W. Software Engineering Standards: A Users Road Map. Los Alamitos, CA: IEEE Computer Society Press, 1997. Myp приводит обзор стандартов IEEE разработки ПО.

Дополнительные ресурсы

Кроме стандартов IEEE, есть и другие источники информации о документировании программ. bttp: cc2e.coni/3208

Spinellis, Diomidis. Code Reading: The Open Source Perspective.

Boston, MA: Addison-Wesley 2003. Эта книга является праг- Интвресно, сколько 8бя*1ких пи-матичным исследованием методик чтения кода. В ней вы сателей никогда не читали дру-найдете советы по поиску нужного кода и чтению больших " авторов, сколько великих - г gi художников никогда не изуча-объемов кода, сведения об инструментах, облегчающих чте- ,роизвбденш других шсте-ние кода, и массу полезных рекомендаций. pos, сколько еысококвалйфици-SourceForge.net. Уже много лет обучению разработке ПО рованньх хирургов никогда не

препятствует проблема поиска реальных примеров готового "" за плечом колле /г- г- г- ги.., И все же именно этого мы

кода, которые можно было бы обсудить со студентами. Мно- ожидаем от программистов, гие люди быстрее всего учатся на реальных примерах, од- j j нако большинство реальных программ является собственностью создавших их компаний. Благодаря Интернету и ПО с открытым исходным кодом эта ситуация улучшилась. Web- mip: cc2e.com/3215

сайт Source Forge содержит код тысяч программ, написанных на С, С++, Java, Visual Basic, РНР, Perl, Python и других языках, причем весь этот код вы можете загрузить из сети совершенно бесплатно. Вы можете проанализировать реальные примеры, гораздо более объемные, чем примеры, приведенные в этой книге. Для начинающих программистов, не имевших ранее дела с объемными примерами готового кода, этот Web-сайт окажется особенно полезен как источник и хороших, и плохих методик кодирования.

Sun Microsystems. «How to Write Doc Comments for the Javadoc

Tool», 2000. В этой статье (http: javasun.com/j2se/javadoc/ mtp: cc2e.com/3222

wntingdoccomments/) описывается применение инструмента

Javadoc для документирования программ Java. Она включает детальное описание разметки комментариев с использованием нотации стиля @tag, 2. также многие конкретные советы по написанию самих комментариев. Конвенции Javadoc являются, наверное, наиболее развитыми из нынешних стандартов документирования на уровне кода.

Ниже указаны источники информации о других аспектах документирования ПО.

McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998. В этой книге описывается документация, необходимая в критически важных проектах среднего размера. На Web-сайте книги вы можете найти много шаблонов документов.



0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 [263] 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.003