Конструиране на качествен програмен кодТеми за курсовите разработки

Версия: 1.0 (официална версия)Последна промяна: 9.12.2002

Автор: Светлин Наков

I. Цел на настоящия документНастоящият документ описва темите, изискванията и критериите за оценяване на домашната

работа (наричана още “курсов проект” или “курсова разработка”) за студентите, записали изборния курс “Конструиране на качествен програмен код” през учебната 2002/2003 година към ФМИ на СУ.

II. Цели на домашната работаПисмената разработка за домашна работа, предвидена в учебния план на курса “Конструиране на

качествен програмен код” има няколко основни цели:- да провери знанията на студента по темите, изучавани в курса;- да провери уменията му самостоятелно да изучава и изследва зададен проблем, свързан с темите,

изучавани в курса;- да провери уменията му да организира и систематизира в писмен вид резултатите от направените

проучвания;- да насърчи студента за усърдна и сериозна работата по зададената тема чрез възможност за

публикуване на разработката;- да формира основната част от крайната му оценка.

Идеята е курсовите проекти, които студентите напишат като домашна работа в рамките на курса, да бъдат публикувани в нещо като сборник, учебник или книга по темата. Книгата, която евентуално ще бъде написана и издадена на български език, ще бъде съставена от събраните курсови разработки, предадени от студентите. С цел да няма ощетени студенти откъм авторски права, ако в бъдещата книга (учебник, сборник или каквото се получи) се публикуват части или цели курсови проекти, наричани за краткост текстове, авторът на тези текстове ще бъде ясно отразен. Всеки студент, който предаде като курсова разработка текст, който е достатъчно добър за публикуване и бъде използван за книгата, ще бъде ясно указан като автор (или съавтор) на съответната част от тази книга, в която този текст е използван. Чрез предложената възможност за публикуване на курсовите проекти студентите се насърчават да напишат старателно и качествено разработката си по зададената им тема, като същевременно знаят, че трудът им не отива напразно. Целта е разработката да не бъде едно досадно задължение с цел изкарване на добра оценка, а да се превърне в едно интересно и старателно извършено изследване върху зададената тема.

III. Теми на курсовите разработкиТемите, посочени по-долу, покриват съдържанието на бъдещата книга “Конструиране на

качествен програмен код” и са разпределени между студентите по начин, определен от преподавателите. Целта на разпределението е по всяка тема да пишат приблизително еднакъв брой студенти с приблизително еднакви възможности, изчислени на базата на оценките им от първия тест.

Темите са така организирани, че да покриват съдържанието на проекто-книгата. Въпросите към всяка тема имат за цел да насочат вниманието на студента към задължителните основни моменти, които трябва да бъдат разгледани в разработката. Една добра писмена разработка по зададена тема трябва да изяснява отговорите на зададените към темата въпроси. Тези въпроси са само насочващи и помагат на студента да не пропусне някой важен момент в курсовата си разработка. Разбира се, тези въпроси не

изчерпват всичко, което може да се включи в темата, т.е. студентът има възможност да добави и други основни моменти в работата си.

Следва списъкът на темите. За една тема се счита една подточка заедно с въпросите към нея.

1. Подготовка за конструиране на програмен код1.1. Процеси и методологии за разработка на софтуер Какво е това процес за разработка на софтуер? Защо е необходим? Не може ли без него? Какво представлява традиционният подход за разработка на софтуер (Waterfall Software Development

Process)? Какви са етапите, от които се състои? Какво се случва на всеки от тези етапи? Какви са основните му принципи?

Какво представляват Unified Process и Rational Unified Process (RUP)? Какви са етапите, от които се състоят те? Какво се случва на всеки от тези етапи? Какви са основните принципи на Unified процеса? Какви са предимствата му пред традиционния подход? Какви са слабостите му?

Какво представлява процесът Extreme Programming (XP)? Какви са етапите, от които се състои? Какво се случва на всеки от тези етапи? Какви са основните му принципи? Какво е това “refactoring” и каква връзка има той с XP? Какви са предимствата на XP процеса пред традиционния подход? Какви са слабостите му?

Какво представлява процесът SCRUM? От какви етапи се състои? Какво се случва на всеки от тези етапи? Какви са предимствата му пред останалите процеси? Какви са слабостите му?

Какви други процеси за разработка на софтуер има? Какво е “dX”? Какво е “Adaptive Software Development”? Какво е “Feature Driven Development”? Какво е “Dynamic System Development Method”?

Какви са процесите при “Open Source” проектите? Какви са основните принципи, залегнали в изброените процеси. Какви са техните силни и слаби страни?

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

1.2. Изисквания към системата Какво представляват изискванията към една софтуерна система? Какво трябва да включват те? Има ли полза от качествени софтуерни изисквания? Какви са характеристиките на висококачествените софтуерни изисквания? Какво представлява проверката на изискванията (Requirements Verification)? Какво представлява спецификацията на една софтуерна система (Software Requirements Specification)?

Необходима ли е тя? До колко формално тя трябва да описва функциите на системата? Какво представлява процесът “Software Requirements Engineering”? Какво включва този процес? Какво е “Software Requirements Analysis”? Какво е “Structured Analysis”? Какво е “Object-Oriented

Analysis”? Какво са “Use cases”? Как се събират изисквания за системата чрез “Use cases”? Каква е ролята на клиента при определяне изискванията към системата?

Какво е “Software Requirements Management”? Какви са основните принципи на ефективното управление на изискванията към системата? Как се управляват промените в изискванията? Какви са препоръките за избягване на проблеми, свързани с изискванията към системата?

1.3. Дизайн на на високо ниво в програмирането (архитектура) Какво означава дизайн на високо ниво? Какво включва архитектурата на една система? Какво не

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

застъпен той при различните процеси за разработка на софтуер? Какво е структурен дизайн (Structured Design)? Какво е функционална декомпозиция на системата?

Какви са подходите при структурния дизайн? Какво е top-down composition и bottom-up composition? Какви са стъпките в структурния дизайн?

Какво е обектно-ориентиран дизайн? Какви са неговите основни принципи? Как се използва той за дизайн на високо ниво? Защо обектно-ориентираният дизай е предпочитан?

Какви формални методи за дизайн има? Какви са техните основни принципи? Какви нотации се използват в дизайна? За какво служат те? Какво представляват диаграмите? Какви видове диаграми се използват? Какво е UML? За какво служи той? Каква роля има той в дизайна?

Какви други подходи има при дизайна на високо ниво? Какви са техните принципи, силни и слаби страни?

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

Как можем да бъдем сигурни, че когато е готов, дизайнът е направен добре? Какви са характеристиките на добрия дизайн? Лесно ли се различават добрият от лошия дизайн? Формален процес ли е дизайнът или евристичен? Итеративен процес ли е дизайнът? Защо? Може ли да се използва методът “проба-грешка”? Не е ли неефективен този метод?

Какво е Design Reviеw и има ли нужда от него? Какво е дизайн документация и има ли нужда от нея?

1.4. Необходими условия за започване на конструирането на програмен код Какво е необходимо да се направи преди да се започне с конструирането на кода? Защо е важна подготовката за конструиране на кода? Не може ли без нея? В какво се състои тази

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

Необходими ли са ясни изисквания към системата и функционална спецификация? До каква степен те трябва да са ясни? Трябва ли изискванията да са строго формални? Има ли възможност за доизясняване на изискванията по време на конструирането на кода? Има ли такова нещо като “стабилни изисквания, които не се променят с времето”?

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

Трябва ли да е избран езикът за програмиране преди започване на конструирането на кода? Не може ли този език да се избере и на по-късен етап? Може ли да се използват различни езици в една система?

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

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

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

2. Препоръки за конструиране на висококачествен програмен код2.1. Дизайн

2.1.1. Основни принципи и понятия Какво е това детайлен дизайн? Какво включва детайлният дизайн на една програма или компонент

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

Какво представляват нивата на абстракция? Какво ни дават те? Защо са толкова важни? Какво е абстракция на данните? Какво е абстракция на управлението? Има ли нещо общо с принципа за абстрактност в обектно-ориентираното програмиране? Какви са типичните нива на абстракция в една софтуерна система? Какво общо има принципът “information hiding”?

Какво е модулност (modularity) и каква е ползата от нея? Има ли тя връзка с нивата на абстракция? Какво е функционална независимост? Какво общо имат с нея понятията “cohesion” и “coupling”? Важна ли е простотата на дизайна (simplicity)? Има ли връзка тя с понятията cohesion, coupling и

information hiding? Има ли отношение тя към леснотата на поддръжка на системата? Има ли връзка между нивата на абстракция и простотата на дизайна?

Какви са характеристиките на добрия детайлен дизайн? Каква връзка с качеството на дизайна имат следните понятия: modularity, simplicity, minimum redundancy, understandability, implementability, modifiability, maintainability, device-independency, internationality, extensibility, efficiency, reliability, stability, robustness, reusability, portability, longevity, completeness? Как можем да бъдем сигурни, че когато е готов, детайлният дизайн е направен добре?

2.1.2. Модули и класове Какво е представляват модулите и каква е ползата от тях? Какви са причините за създаване на

модули? Как се реализират модулите в съвременните езици за програмиране (пакети в Java, namespaces в C#)?

Какво представлява интерфейсът на един модул? Какво трябва да включва? Какво не трябва да включва? Какво представлява интерфейсът на един клас в обектно-ориентираното програмиране? Какво е “information hiding”? Кога и защо трябва да се прилага и каква е ползата от тази техника? Коя информация трябва да се скрива и коя не трябва? Има ли връзка скриването на информация с концепцията за разделяне на програмата на нива на абстракция?

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

Какво е абстракция на данните и скриване на информация? Какво е енкапсулация? Какво гласят принципите за здравина на модулите (module cohesion) и слаба модулна свързаност

(module coupling)? Как се пренасят тези принципи в обектно-ориентираното програмиране? Какво са “interface object coupling”, “internal object coupling” и “object cohesion”? Как се реализират тези принципи на практика? Виниги ли трябва да се спазват? Винаги ли е възможно да се спазват?

Как се постига лесна преносимост (portability) и лесна повторна употреба на кода (reusability)? Какви са конкретните стъпки в дизайна на един модул (клас)? Какво се случва на всяка от тези

стъпки? Кога може да се счита, че дизайнът на един модул (клас) е добър? Какво е “добро име” на модул? На какви изисквания трябва да отговарят имената на модулите? Какво е “добро име” на клас? На какви изисквания трябва да отговарят имената на класовете?

2.1.3. Обектно-ориентиран дизайн Може ли да се каже, че обектно-ориентираното програмиране е следващата стъпка от

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

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

Кога трябва да се използва? Какво е множествено наследяване и има ли полза от него? Какво е полиморфизъм и има ли той някаква роля в дизайна на една система? За решаването на какви дизайн проблеми може да се използват наследяване и полиморфизъм? Какво е “operator overloading” и каква е ролята на тази техника? Какво представляват шаблоните

(templates) и кога трябва да се използват? Какви други техники предоставя обектно-ориентираното програмиране и за какво се използват те?

Какво представляват шаблоните за дизайн (Design Patterns)? Какво ни помагат тези шаблони? Кога трябва да се използват?

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

Какво представляват следните отношения между обектите: aggregation, association, composition, generalization, delegation? Каква роля играят те в обектно-ориентирания дизайн?

2.1.4. Подпрограми Какво е подпрограма? Защо трябва да се използват подпрограми? С какво използването на

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

Какво е здравина на подпрограма (routine cohesion)? Какви типове routine cohesion има? Кои от тях трябва да се предпочитат и кои да се избягват?

Какво е свързаност на подпрограма (routine coupling)? Какви типове routine coupling има? Кои от тях трябва да се предпочитат и кои да се избягват?

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

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

на всяка от тези стъпки? Защо процесът е евристичен и итеративен, а не строго формален? Какво е “добро име” на подпрограма? На какви изисквания трябва да отговарят имената на

подпрограмите, в частност на процедурите, на функциите и на методите в класовете?

Какви са препоръките при дефиниране и използване на параметрите в подпрограмите? Какви трябва да бъдат имената на параметрите? Трябва ли read-only параметрите да са изрично декларирани като такива (с const при C++ и Pascal и final при Java)? Какви са съветите за избор на механизъм за предаване на параметрите (по адрес, по стойност и т.н.)?

Какво е псевдокод? За какво служи той? Кога трябва да се използва и кога не? Какво представлява процесът за създаване на подпрограми чрез псевдокод (PDL-to-code process)?

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

Какви други методи за създаване на подпрограми има? Защо не може строго да се формализира процесът за създаване на подпрограма?

2.2. Данните в програмирането

2.2.1. Създаване на данни. Имена на променливите За какво служат данните в програмирането? Как се дефинират и как се използват? Какво представляват собствените типове данни? Каква е ползата от тях? Какви са препоръките

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

инициализирането на променливите? Какво означава променливата да има добро име? Какви са конкретните препоръки за имената на

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

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

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

програмиране (C++, Java, C#)? Какво представлява унгарската нотация и има ли полза от нея? Защо в силно-типизираните езици

тя не е необходима?

2.2.2. Препоръки за правилното използване на променливите Какви са основните правила за правилно използване на променливите? Какви са препоръките за видимостта на променливите (variable scope)? Трябва ли да се избягва използването на променливи без да се декларират предварително в

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

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

Какво представляват “variable lifetime” и “span”? Каква е връзката между “scope”, “lifetime” и “span”? Какво се препоръчва в тези насоки?

2.2.3. Работа с фундаменталните типове данни Какво е фундаментален тип данни? Какви са препоръките за работа с числови данни в програмирането? Какви са препоръките за работа с целочислени променливи? Как се избягват проблемите с

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

закръглянето при работа с реални числа с плаваща запетая? Какви са препоръките за работа със символни данни? Какви видове символни низове (стрингове)

има? Какви са предимствата и недостатъците им? Какво трябва да знаем за символните низове при различните езици за програмиране (C, C++, Java, Pascal, C#)?

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

Какви са препоръките за работа с масиви? Какви са препоръките за работа с указатели в езиците, в които се поддръжат? Може ли да се счита,

че работата с указатели е опасна и трябва да се избягва? Лошо ли е да се използва директен достъп до паметта на ниско ниво посредством указатели? Защо такива техники, типични за езици от ниско и средно ниво (като Assembler и C) не са позволени в езиците от по-високо ниво като Java и C# (C# managed code)?

Какви са препоръките за работа с типизирани указатели (references) в езиците, в които се поддръжат? Защо те се считат за по-безопасни от обикновените указатели? Може ли да се твърди, че типизираните указатели са “указатели от високо ниво”, които са възникнали като резултат от еволюцията на обикновените указатели?

Какви са препоръките за работа с променливи от тип клас (обекти)? Какво трябва да знаем за жизнения цикъл на такива променливи. Какво общо имат конструктурите и деструктурите?

2.2.4. Сложни типове данни Какви данни, освен фундаменталните, има в програмирането? Кога трябва да се използват структури и записи? Какви са препоръките за правилното им

използване? Какво е сериализация на структура данни? Какви са препоръките при сериализиране и

десериализиране на структури данни? Какво представляват lookup-таблиците? Кога се използват? Каква е ползата от тях? Какви са

препоръките за правилното им използване? Винаги ли може логиката от програмата да се трянсформира в данни чрез lookup-таблици? Колко вида търсене в lookup-таблица има? Какво е директен достъп? Какво е номериран достъп? Какво е индексиран достъп? Какво е трансформация на ключа за достъп? Какви данни могат да съдържат елементите на една lookup-таблиците?

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

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

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

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

Какво е граф? Какво е дърво? Какви видове дървета има? За какво и кога се използват? Какво е XML и каква е връзката между този език за описание на данни и дърветата? Какви са препоръките за правилното използване на дървета?

Какво е файл? Какво е индексен файл? Какво са потоците от данни (streams)? Какви са препоръките при използване на тези структури от данни?

2.3. Изрази и правилната работа с тях Какви изрази се срещат в програмирането? Трябва ли да се избягват сложни изрази в програмата? Как могат да се опростяват сложните изрази?

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

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

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

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

2.4. Конструкции за управление в програмата

2.4.1. Организиране на праволинейния код. Условни конструкции за управление Какво е праволинеен код? Какви са препоръките за организация на праволинейния програмен код? Как трябва да се организират изрази, които зависят един от друг? Как трябва да се организират изрази, които не зависят един от друг? Има ли значение тяхната

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

Какви са препоръките за организация на условните конструкции за управление? Какви са препоръките за организация на if-then-else конструкциите и веригите от такива

инструкции? Какви са препоръките за организация на switch конструкциите?

2.4.2. Цикли Какво е цикъл? Какви видове цикли има? Какви са препоръките при организирането на цикли? Кога се използват условни цикли с проверка на условието в началото (while-цикли)? Кога се

използват цикли с проверка за изход в края (do-while-цикли)? Кога се използват цикли с изход? Кога се използват for-цикли?

Кога и как трябва да се инициализират променливите, участващи в цикъла? Какво трябва да се случва в началото на цикъла? Какво трябва да се случва в тялото на цикъла? Как трябва да приключва работата на цикъла? Може ли да се използват break и continue и ако може, кога се препоръчва?

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

рамките на една подпрограма?

2.4.3. Необичайни конструкции за управление. Блокове. Вложеност на структурите за управление. Рекурсия

Какви необичайни конструкции за управление се срещат в езиците за програмиране от високо ниво?

Вредно ли е използването на оператора за безусловен преход goto? Какви аргументи има “за” и “против” използването на goto? Ако goto все пак се използва, как може това да става “безопасно”? Кога се налага да се използва goto? Какви техники за избягване на оператора goto има? Заместват ли тези техники действието на goto? Трябва ли goto да се премахне от езиците за програмиране от високо ниво?

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

Вредни ли са операторите за изход от цикъл break и преход към края на цикъла continue? Какво е структурно програмиране и какво общо има то със спора дали операторът goto е вреден? Какви са препоръките за използване на блокове в програмата? Опасно ли е дълбокото влагане на

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

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

Вярно ли е твърдението на Никлаус Вирт, създателят на езика Паскал, че “рекурсивните структури от данни се обработват с рекурсивни алгоритми”? Винаги ли трябва да се прибягва до използването на рекурсия при обработката на рекурсивни структури данни?

2.5. Многонишково програмиране и синхронизация Какво е конкуретно програмиране? Какво е многонишково програмиране (multithreading) и защо е

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

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

Какви конфликти възникват при конкуретния достъп до общи ресурси? Какво е синхронизация? За какво е необходима тя? Как се реализира? Какви средства за синхронизация предлагат различните езици за програмиране и различните платформи? Какво е мъртва хватка (dead-lock)? Какви са препоръките за правилна синхронизация и избягване на мъртвата хватка?

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

Какви средства за многонишково програмиране и синхронизация дават различните платформи (UNIX, Windows, Java, .NET)?

2.6. Обработка на грешки и непредвидени събития по време на изпълнение

2.6.1. Защитно програмиране. Управление на изключенията (Exceptions Handling) Какво означава защитно програмиране? Кога и как трябва да се използва? Какво е представляват предпазните проверки (assertions)? За какво служат? Кога трябва да се

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

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

Какво представлява механизмът на изключенията (exceptions) в обектно-ориентираното програмиране? За какво служи този механизъм? Как се реализира в съвременните обектно-ориентирани езици (C++, Java, C#)? Какви са му предимствата пред стандартния подход за обработка на грешки и непредвидени обстоятелства? Какви са препоръките за правилното му използване? Какви са опастностите, които крие той и как могат да се избегнат?

Полезно ли е създаването на йерархии от изключения? С какво ни помагат те? Кога и как трябва да се използват?

Кога една подпрограма трябва да връща грешките като резултат от извикването си или в изходен параметър и кога трябва да генерира изключение? Кой от дават механизма за обработка на грешки трябва да се предпочита? Могат ли да се смесват двата механизма?

2.6.2. Сигурен програмен код Какво е сигурен програмен код? Какви могат да бъдат последствията от несигурен програмен код?

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

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

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

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

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

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

често срещаните опасности в съвременните езици за програмиране? Какви са опасностите в C и C++? Какви са опасностите при използване на SQL и динамично състявяне на заявките към базата? Какви са опасностите в Perl и PHP? Какви са опасностите в Java? Какви са опасностите в C#? Какви са опасностите при другите езици и платформи и как да се предпазим от тях?

Зависи ли сигурността на програмата от това дали кодът й е отворен? Какво е “reverse engineering”, кой го използва и защо? Вярно ли е че дори в затвореният код не може да има тайни? Какво означава “code obfuscation”?

2.7. Оформление и форматиране на програмния код

2.7.1. Оформление и форматиране на блоковете в програмата Защо е важно как е форматиран програмният код? Каква е ползата от доброто форматиране? Кои са основните принципи за доброто форматиране на кода? Какво гласи фундаменталната

теорема на форматирането на кода? Как се форматира празното пространство в програмата (интервали, табулации, нови редове)? Как

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

Какви стилове има за оформление на блоковете в програмата? Какво представляват естествените блокове (pure blocks), изградени от синтактичните елементи на

конструкциите за управление на езика, които са типични за някои езици за програмиране като Basic и Ada? Какви са предимствата на този подход за оформяне на структурата на програмата?

Какво е оформление на блоковете в стил “блокове вдясно от края на реда” (end-line layout)? Какво е оформление на блоковете в стил “имитация на естествени блокове”, когато скобата за

начало на блок е на същия ред, за скобата за край е под оператора за управление, за който се отнася блока?

Какво е оформление на блоковете в стил “отместен блок на следващия ред” (begin-end layout)? Кой от изброените стилове е най-добрият? Защо? Кой стил трябва да се използва? Могат ли да се

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

структурата й? Може ли да се счита за вредна двойната идентация, типична за езика Pascal? Трябва ли да се оставят празни редове в програмата? Защо операторът goto не може да се форматира по начин, който отразява структурата на програмата?

2.7.2. Оформление и форматиране на останалите елементи на програмата Как се форматират индивидуалните изрази? Каква трябва да е максималната дължина на редовете?

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

2.8. Документация на кода и коментари Какво е документация на кода? Какви видове документация на кода има? Какво представляват коментарите в програмата? За какво се използват? Кога трябва да се използват? Кога един фрагмент от кода трябва да се коментира и кога не? Какви типове коментари съществуват? Защо в кода не трябва да има закоментирани програмни фрагменти? Какви са препоръките за правилно използване на коментарите в програмирането? Как се коментират

отделни редове в програмата? Как се коментират отделни фрагменти от код в програмата? Как се коментират декларациите на променливите? Как се коментират конструкциите за управление?

Как се коментират процедурите, функциите и методите? Как се коментират класовете, модулите и файловете на програмата? Какво представляват стандартите за документация в стил JavaDoc в езици като Java и C#?

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

2.9. Код конвенции Какво е представляват код конвенциите? Защо са необходими? Кога трябва да се използват? Има ли

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

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

включва една такава конвенция?

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

Какво представляват конвенциите за именоване на елементи (методи, променливи и т.н.) с подобно предназначение?

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

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

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

Трябва ли конвенцията за кода да е неделима част от езика за програмиране или платформата? Има ли опити за такава интеграция? Добре ли ще е, ако компилаторите не компилират код, който не съответства на конвенцията, която е заложена в тях? Няма ли така да се наложи единствена за всички конвенция? Има ли полза от такава единствена конвенция?

2.10. Помощни средства и инструменти за конструиране на програмен код Какво представляват помощните средства за конструиране на програмен код (programming tools)?

Какви типове такива средства има? За какво служат? С какво помагат на програмиста? Какво представляват инструментите за софтуерен дизайн? Какво представляват средствата за

моделиране с UML и средствата за създаване на клас-диаграми? Какво представляват средствата за работа със сорс-код? С какво те ни помагат? Какво включват

добрите текстови редактори за сорс-код? Какво представляват инструментите за разглеждане и претърсване на сорс-код? Какво представляват анализаторите на сорс-код? Могат ли те да ни дадат конкретни съвети за качеството на кода и как успяват да открият потенциални проблеми в него? Какво представлява “Version Control” софтуерът и защо трябва задължително да се ползва при работа в екип?

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

Какво е profiler? Как програмистът може сам да създаде помощни средства за своята работа и защо понякога е

необходимо? Какво представляват интегрираните среди за разработка на софтуер (IDE – Integrated Development

Environment)? Какво включват те? Защо се предпочитат пред отделните независими инструменти? Какви други средства, подпомагащи писането на програмен код има? За какво служат и каква е

ползата от тях?

3. Контрол над качеството на софтуера3.1. Общи принципи Какви са критериите за качество на софтуера от гледна точка на протребителя и от гледна точка на

програмиста? В какво се различават гледните им точки? В какво се състои процеса на контрол над качеството на софтуера? Какво включва този процес? Как се изгражда концепция за тестване (testing concept)? Какво трябва да включва една такава

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

code review? Какво най-общо представлява процеса на тестване на софтуера и какви видове тестване включва? Какво представлява процеса на откриване, систематизиране и отстраняване на дефектите? Защо е необходима оценка на процеса на разработка (assessment)?

3.2. Code Reviews Какво представляват код-ревютата (code reviews)? Каква е ролята им в процеса на осигуряване на

качество на софтуера (software quality assurance)? Важни ли са те? Каква е ползата от тях? Кога трябва да се правят?

Какви типове код-ревюта има? Какво е характерно за тях? Какво представлява формалната процедура, наречена “инспектиране на код” (inspections)? Какви са

нейните основни принципи? Колко души взимат участие в една такава инспекция? Каква е ролята на всеки от тях? Как протича една инспекция? От какви стъпки се състои? Какво се случва на всяка от тези стъпки? Какви психологически фактори могат да указват влияние върху инспециите? Каква е ефективността на инспекциите?

Какво представлява процедурата наречена “walkthrough”? Какви са нейните основни принципи? Колко души обикновено взимат участие в една такава процедура? Каква е ефективността й?

Какво представлява процедурата наречена “четене на кода” (code reading)? Какви са нейните основни принципи? Каква е ефективността й?

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

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 см- шрифтове:

o за заглавието: Times New Roman, 20, Center Alignmento за подзаглавията: Times New Roman, 16, Left Alignmento за детайлните подзаглавия: Times New Roman, 14, Left Alignmento за тялото на разработката: Times New Roman, 12, Justified Alignment

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

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

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

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

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

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

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

2.2. Подтема 2. Информация за тази подтема и проблемите, които тя включва. Факти и примери в полза на изтъкнатото в тази подтема твърдение. Изводи и разсъждения, направени на базата на изтъкнатите твърдения

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

момента.

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

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

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

издаване, издадетлство, ISBN

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

- съдържание: o изчерпателно, коректно и добре организирано представяне на информацията по зададената

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

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

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

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

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

IV. Скелет на примерна разработка по тема 1.1Примерен скелет на една писмена разработка, отговаряща на изискванията, описани в настоящия

документ е дадена във файла Example-Paper.rtf.