I. Цел на настоящия документ



страница7/7
Дата08.06.2017
Размер385.9 Kb.
#23135
1   2   3   4   5   6   7

3.3.Тестване


      • Какво представлява процеса на тестване?

      • Какви видове тестове се практикуват? Кой е отговорен за реализирането и изпълнението на всеки един от тези видове тестове? В кои етапи на разработката на приложението е необходимо да се изпълняват отделните видове тестове?

      • Какво ни дава автоматизацията на тестването? Има ли смисъл в изработването на сложни автоматизирани тестове?

      • В какво се изразява концепцията за Regression тестване? Какви са предпоставките за успешното й прилагане?

      • Какво представляват частичните тестове (unit tests)? Какво включват? Кога се пишат unit тестове и каква е ползата от тях? Кой е отговорен за създаването и поддръжката им? Не забавят ли те процеса на разработка? До каква степен на детайлност е реалистично да се стига при писане на unit тестовете?

      • Какво е system или component тест? Какви са предпоставките за започване на такъв вид тестове? Как протичат и как се изпълняват тези тестове?

      • Какво е functional тест? Какви са предпоставките за започване на такъв вид тестове? Интеграционно тестване?

      • Какво представляват тестовете stress, load, scalability и какви са разликите между тях?

      • Какво е Test coverage?

3.4.Откриване и отстраняване на грешки (Debugging)


      • Как се откриват грешки в програмата и как се поправят откритите грешки? Какви са препоръките, които помагат за по-лесно откриване и правилно поправяне на грешките?

      • Какви типове грешки се срещат в програмите?

      • Важно ли е да разбираме добре програмата за да търсим грешки в нея?

      • Какви са препоръките за ефективно намиране на грешките? Какви са стъпките за намиране на точното място на грешките в програмата? Какво се случва на всяка от тези стъпки?

      • Как се поправят откритите в програмата грешки? Какви са препоръките за правилното и ефективно порравяне на грешки?

      • Какви програмни техники за откриване на грешки има? Какво представляват мeханизмите за записване и следене на полезна информация за работата на програмата по време на нейното изпълнение, известни като “логване” и “дъмпване” на съобщения? Какво представлява техниката за вграждане на код в програмата, предназначен да тества някои нейни фрагменти, известна като scaffolding? Как може да се откриват проблеми с паметта, например загуба на памет?

      • Какви инструменти за откриване и поправяне на грешки (debugging tools) има? С какво компилаторът помага за намиране на грешки в програмата? Какво предствляват дебъгерите и с какво са полезни? С какво са полезни profiler-ите?

4.Системна интеграция


      • Какво е системна интеграция? Какво включва тя? Кога се извършва? Защо е необходима и винаги ли е необходима?

      • Трябва ли да се използва някаква стратегия при интеграцията на компонентите на системата в едно цяло? Важно ли е каква е стратегията? Има ли значние големината на проекта?

      • Какво представлява “phased” интеграцията?

      • Какво представлява “incremental” интеграцията? Има ли полза от този подход за интеграция? По-добър ли е той от “phased” интеграцията?

      • Какви стратегии за “incremental” интеграция има? Какво e “tow-down” интеграция? Какво e “bottom-up” интеграция? Какво e “sandwitch” интеграция? Какво e “risk-oriented” интеграция? Какво e “feature-oriented” интеграция? Какви са нейните основни принципи на всеки от изброените типове интеграция?

      • Какво означава поетапна разработка на софтуер (evolutional delivery)? Винаги ли е подходящо софтуерът да се планира, създава и доставя на няколко етапа – като отделни версии на един и същ продукт? Какви стъпки и процеси включва тази стратегия на поетапна разработка на софтуер? Каква е ползата от тази стратегия?

      • Какво е prototyping и каква е връзката му с поетапната разработка на софтуер?

      • Какви са лошите страни на поетапната разработка?

      • Какви други стратегии за системна интеграция има?

      • Зависи ли системната интеграция от процеса за разработка на софтуер, който се използва?

5.Оптимизация на кода

5.1.Оптимизация на кода на ниво дизайн


      • Какво означава понятието “оптимизация на кода”? Кога трябва да се прави? Кога не трябва да се прави? Вярно ли е правилото, че оптимизирането трябва да се прави само ако е абсолютно наложително? Вярно ли е, че оптимизацията на кода влошава четимостта му? Какво означава ефективност на програмата? В какви други насоки, освен бързодействие, може да се оптимизира един програмен фрагмент? Има ли значение размерът на използваната памет? Има ли значение размерът на полученият след компилиране изпълним код?

      • Какви подходи има при оптимизацията на програмен код? Какво представлява оптимизирането на ниво дизайн? Какво представлява оптимизирането на ниво имплементация? Коя от двете насоки в оптимизирането на кода е по-ефективна?

      • Имат ли значение използваните структури от данни за ефективността на кода? Какви структури от данни трябва да се използват за по-голяма ефективност? Какви са най-често срещаните структури от данни и при какви условия всяка от тези структури е оптимална?

      • Има ли значение използваният алгоритъм за ефективността на програмата? Какво е сложност на алгоритъм? Как се изчислява сложността на един програмен фрагмент? Винаги ли сложността на един алгоритъм е решаваща за скоростта му на изпълнение?

      • Какво представлява оптимизационната техника “precomputation”? Кога може да бъде приложена? Какво се печели от нея? Каква е връзката между нея и lookup-таблиците като структура от данни?

      • Как може да се избегне неколкократното изчисляване на една и съща стойност като част от някакво по-голямо изчисление? Какво е кеширане на вече изчислени стойности и как се прилага?

      • При използване на “precomputation” задължително ли е всички стойности от “precomputation” таблицата да се изчислят предварително? Възможно ли е те да се изчисляват в момента, в който потрябват и все още не са били изчислени (compute on demand)?

      • Как може да се направи индексиране с цел ускоряване на дадена операция? Може ли такова индексиране да се счита за “precomputation”?

5.2.Оптимизация на кода на ниво имплементация


      • Какво означава оптимизиране на кода на ниво имплементация? Какво е настрoйка на кода (code tuning)?

      • Как могат да се оптимизират циклите в програмата? Какво представляват техниките “unswitching”, “jamming” и “unrolling”. Кога е възможно да се прилагат тези техники? Помага ли минимизирането на работата в тялото на цикъла за неговата оптимизация? Полезни ли са фиктивните стойности при цикли за търсене и могат ли те да подобрят скоростта на изпълнение на съответния цикъл? Има ли значение за бързодействието на вложени цикли тяхната подредба? Какво означава редуциране на сложността на аритметичните операции (strength reduction)? Кога може да се приложи?

      • Как могат да се оптимизират логическите конструкции в програмата? Трябва ли да се довършва изчислението на булев израз, ако вече е известен резултатът? Подобрява ли бързодействието преподреждането на сравненията в булев израз по честота на срещане? Може ли използването на lookup-таблици при сложни булеви изрази да подобри скоростта?

      • Как могат да се оптимизира за скорост работата с данни? Вярно ли е че работата с цели числа изисква по-малко време отколкото ако се използват реални числа? Как могат изчисления с реални числа да се заместват с еквивалентни изчисления с цели числа? Вярно ли е че достъпът до двумерен масив е по-бавен отколкото до едномерен, ако двата масива съдържат еднакъв брой елементи? Вярно ли е, че достъпът до елемент на масив е по-бавен, отколкото достъп до обикновена променлива?

      • Как могат да се оптимизират изрази? Помагат ли математическите твърдения при оптимизацията на изрази? Помага ли използването на по-бързи типове данни на мястото на по-бавни (strength reduction)? Възможно ли е подобряване на ефективността чрез извършване някои инициализации по време на компилация, вместо по време на работа на програмата? Помага ли използването на константи вместо извиквания на функции? Има ли значение от какъв тип е обявена константата? Подобрява ли скоростта елминирането на общите подизрази при изчисляване на даден израз?

      • Как използването на подпрограми се отразява на скоростта на програмата? Има ли смисъл от “inline” подпрограми? Има ли смисъл от писане на асемблерен код за някои критични за бързодействието фрагменти от кода? При съвременните процесори не е ли много сложно да се напише ефективен код?

6.Еволюция на софтуера и преработка на съществуващ код

6.1.Еволюция на софтуера и софтуерна поддръжка


      • Какво означава поддръжка на софтуера? Какви процеси включва? Какво означава поддръжка на кода? Какви типове поддръжка има? Защо поддръжката е толкова тежка задача? Какви са стъпките при извършване на промяна в работеща система в рамките на поддръжката по нея? Какво се случва на всяка от тези стъпки?

      • Какво е софтуерна еволюция? Каква е причината за нейното настъпване?

      • Вярно ли е че софтуерната еволюция трябва да води до подобряване на качеството на кода, а не до влошаването му?

      • Какви са генералните препоръки при промяна на кода?

      • Какви са препоръките при добавяне на нови подпрограми с цел разширяване или изменение на функционалността? Кога се препоръчва да се добават нови подпрограми? Трябва ли винаги, когато добавяме нова подпрограма, да се стремим тя да намалява сложността на кода, а не да я увеличава?

      • Какви други начини за намаляване на сложността и подобряване на четимостта има?

      • Какви са подходите при промяна на подпрограма с цел добавяне на функционалност? В какво се състои подходът “share code at a higher level”? В какво се състои подходът “share code at a lower level”? Кога трябва да се използва всеки от тези два подхода? Има ли други подходи?

      • Какво друго е характерно за софтуерната еволюция?

6.2.Преработка на съществуващ програмен код (Refactoring)


      • Какво означава преработка на съществуващ програмен код (Refactoring)? Защо е необходимо да се прави? Кога е необходимо да се прави такава преработка?

      • Какво включва преработката на кода? Има ли отношение тя към преработката и на дизайна?

      • Какво е необходимо да се направи преди да се започне с преработването на кода? Какво отношение имат Unit-тестовете към преработката? Възможна ли е преработка на код, за който няма Unit-тестове?

      • Кои са критериите, които трябва да ни карат да се замислим дали кодът има нужда от преработка (bad smells in code)?

      • Какви са основните техники за преработка на съществуващ код? Как могат да се преработват методи и подпрограми? Как може да се премества функционалност между различни обекти, класове и методи? Как могат да се реорганизират данните в програмата? Как могат да се опростят условните изрази? Как могат да се опрости начинът на извикване на методите? Как се преработват отношенията между класовете в обектно-ориентирания модел на програмата?

      • Къде се вписва преработката на кода в процеса на разработка на софтуер?

      • Какви инструменти за преработка съществуват? Има ли нужда от такива инструменти, за да се извършва преработка на кода?

7.Управление на конструирането на код


      • Какво включва управлението на процеса на конструиране на програмен код?

      • Заявиси ли конструирането на програмния код от големината на проекта? Зависи ли от процеса за разработка на софтуер, който се прилага? Има ли отношение големината на проекта към продуктивността на работа и количеството грешките в кода?

      • Как може да се насърчат програмистите да пишат качествен код? Какви конкретно мерки могат да се предприемат в тази насока в една организация?

      • Как трябва да се управляват промените в изискванията, дизайна и кода на един проект? Трябва ли да има формални процедури за промяна на дизайна? Как трябва да се управляват промените в кода? Задължително ли е използването на “version control” софтуер при работа в екип? Трябва ли да се използват редовно системи за backup?

      • Как се изчислява обемът на работата по един проект? Как се изчислява необходимото време и ресурси за разработката на един проект? Точно ли е едно такова изчисление? Какво представлява мерната единица “човеко-месец”? Вярно ли е че ако един човек може да напише даден проект за 6 месеца, то 6 човека могат да го напишат за 1 месец?

      • Каква част от работата по проекта се пада на конструирането на кода? Има ли значение големината на проекта?

      • Какви са факторите, от които зависи правилното изчисляване на времето, необходимо за разработка на един проект? Има ли формални методи, изчисляващи влиянието на тези фактори?

      • Как трябва да се организира работата на един екип? Зависи ли това от големината на екипа и от големината на проекта?

      • Какво може да се направи, ако един проект закъснява от сроковете?

      • Трябва ли програмистите да се третират като хора? Важно ли е това за продуктивността и качеството на работата им? Има ли значение за производителността сработването на програмиста с екипа? Имат ли значение условията за работа на работното място за качеството и производителността на програмистите?

      • Трябва ли програмистите да се борят със своите началници? Как трябва да постъпват, когато се сблъскат с некомпетентни началници и колеги? Трябва сляпо да изпълняват указанията на началниците си, когато те са неадекватни и безсмислени?

8.Психология на програмирането

8.1.Характерът на програмиста


      • Какво влияние указва характерът на програмиста като човек върху работата му като програмист?

      • Необходимо ли е да един човек да е супер интелигентен, за да бъде добър програмист?

      • Необходимо ли е програмистът да е скромен и защо?

      • Необходимо ли е програмистът да е любопитен и защо? Помага ли му любопитството при разработката на софтуер? Трябва ли той да знае повече за програмирането, отколкото е необходимо, за да си върши всекидневните задължения? Трябва ли програмистът, за да е добър, да се стреми към непрекъснато усвояване на нови знания и технологии? Не може ли да научи всичко в неговата област и след това да използва само тези знания до края на кариарата си?

      • Трябва ли програмистът да бъде честен в работата си? Трябва ли да си признава, когато не познава дадена технология, вместо да се прави на компетентен? Трябва ли да си признава грешките, дори пред подчинените си? Трябва ли да дава реалистични оценки за сроковете на разработка, дори ако е подложен на натиска на началниците си?

      • Важно ли е за програмистите да са комукативни? Важно ли е да могат да работят добре в екип, заедно с другите програмисти? Вярно ли е че дори най-добрият програмист не може да постигне толкова, колкото добър, сплотен колектив от далеч по-слаби програмисти?

      • Важен ли е талантът за програмиране? Важно ли е програмистът да подхожда творчески към задачите?

      • Важна ли е самодисциплината в програмирането?

      • Лош ли е мързелът за програмирането? В какво може да се изразява този мързел? Не спомага ли той за развитието на технологиите?

      • Важни ли са организираността и сериозното отношение към работата?

      • Важни ли са упоритостта и постоянството?

      • Голямо ли е значението на опита? Вярно ли е че програмистите с много опит са добри, а тези с по-малко опит са по-слаби?

      • Каква е ролята на навиците в програмирането? Вредни ли са те или полезни? Как може да се промени вреден навик?

      • Какви други персонални качества на програмиста имат отношение към работата му?

      • Какви трябва да са взаимоотношенията между QA Engineer-ите и Developer-ите? Какви са правата и задълженията им?

8.2.Стремежът към намаляване на сложността на кода


      • Защо при качествения програмен код има стремеж да се намалява сложността? Вярно ли е че човешкият мозък има ограничени способности и това е причината да се търси простота при софтуерния дизайн и програмирането? Защо лесната четимост на кода се смята за толкова важна за неговото качество? Как може да се намалява сложността на кода? Защо при дизайна на софтуер има йерархичност и опростява ли тя проблема? Каква е връзката на абстракциите в софтуерния дизайн с простотата на софтуера?

      • Важна ли е организацията за успеха на проекта?

      • Защо програмите трябва да се пишат за хората, които ги четат, а не за компютрите, които ги изпълняват?

      • С какво помагат конвенциите? Водят ли те до опростяване на програмния код?

      • Трябва ли когато се програмира да се използват термините от сферата на проблема вместо термините от сферата на програмирането? Трябва ли да се работи на най-високото възможно ниво на абстракция? Каква е връзката на нивата на абстракция с простотата на софтуера?

      • Защо в много от процесите, които са част от разработката на код, се използва итеративен подход, при който се пробват много различни подходи, докато се намери подходящият?

      • Защо разработката на софтуер не е формална наука, а по-скоро изкуство?

      • Какви други други психологични фактори имат отношение към програмирането?


III. Технически изисквания за курсовите разработки

Курсовите разработки трябва да представляват текстове на български език, оформени като Word документи и записани в RTF файл.

Изискванията за форматирането на тескта са следните:


  • формат на страниците: A4

  • разстояния от ляво, отдясно, отгоре и отдолу на страницата: 1,5 см, 1,5 см, 2 см, 2 см

  • шрифтове:

    • за заглавието: Times New Roman, 20, Center Alignment

    • за подзаглавията: Times New Roman, 16, Left Alignment

    • за детайлните подзаглавия: Times New Roman, 14, Left Alignment

    • за тялото на разработката: Times New Roman, 12, Justified Alignment

  • редове на страница: между 45 и 60 (приблизително)

  • колони на ред: между 80 и 110 (приблизително)

Изисквания за форматирането на текста са приблизителни и затова не е сериозен проблем ако има малки разминавания спрямо посочените.

Всяка курсова разработка трябва да съдържа заглавието на темата заедно с номера й, както е зададено в списъка с темите. След заглавието трябва да има информация за автора на разработката –трите имена, фак. номер, курс и специалност.

Курсовите разработки трябва да имат следната структура:


  1. Въведение в темата. Няколко изречения, които изясняват за какво става дума в разработката и какво предстои да бъде представено като информация и изводи в същинската част на работата.

  2. Същинска част (тяло на разработката). Съдържа същината на разработката, която е съставена от подтеми и изводи. Споменатите подтеми могат да бъдат формулирани на базата на въпросите към темата, която се разработва и трябва да са отделени една от друга в отделни абзаци. Препоръчва се следната структура за тялото на разработката:

    1. Подтема 1.

  • Информация за тази подтема и проблемите, които тя включва.

  • Факти и примери в полза на изтъкнатото в тази подтема твърдение.

  • Изводи и разсъждения, направени на базата на изтъкнатите твърдения

    1. Подтема 2.

  • Информация за тази подтема и проблемите, които тя включва.

  • Факти и примери в полза на изтъкнатото в тази подтема твърдение.

  • Изводи и разсъждения, направени на базата на изтъкнатите твърдения

    1. ... ... ...

    2. ... ... ...

    3. ... ... ...

    4. Общи изводи, направени на базата на всички проблеми и твърдения, разгледани в подтемите до момента.

  1. Заключение. Съдържа обобщение на изтъкнатото в темата и включва важни изводи, направени от информацията, поднесена в цялата разработка.

  2. Библиография. Препоръчва се следната структура:

  1. за Интернет ресурси: автор (име фамилия), “Заглавие на публикацията”, година на издаване, адрес в Интернет

  2. за книги: автор (име фамилия), втори автор (име фамилия), ..., “Заглавие на книгата”, година на издаване, издадетлство, ISBN


III. Критерии за оценка на курсовите разработки

Критериите за оценяване на курсовите разработки са следните:



  • съдържание:

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

    • правилно, коректно и изчерпателно отговаряне на насочващите въпроси от съдържанието на темата

  • обем на разработката:

    • между 5 и 30 страници текст съгласно техническите изисквания за форматиране на страниците

    • схемите, фигурите, илюстрациите и изходния код на програмите, съдържащи се в текста не влизат в размера на текста, т.е. не се считат за част от необходимите от 5 до 30 страници

  • добър научен стил


IV. Скелет на примерна разработка по тема 1.1

Примерен скелет на една писмена разработка, отговаряща на изискванията, описани в настоящия документ е дадена във файла Example-Paper.rtf.

Сподели с приятели:
1   2   3   4   5   6   7




©obuch.info 2024
отнасят до администрацията

    Начална страница