syllabus
1. Information regarding the programme
1.1 Higher education institution 	Babeş Bolyai University	
1.2 Faculty	Faculty of Mathematics and Computer Science	
1.3 Department	Department of Computer Science	
1.4 Field of study	Computer Science	
1.5 Study cycle	Bachelor	
1.6 Study programme / Qualification 	Computer Science	

2. Information regarding the discipline 
2.1 Name of the discipline	Individual Project	
2.2 Course coordinator 	Lect. PhD. Grigoreta Cojocar	
2.3 Seminar coordinator	Lect. PhD. Grigoreta Cojocar	
2.4. Year of study	2	2.5 Semester	3	2.6. Type of evaluation	C	2.7 Type of discipline	Compulsory	

3. Total estimated time (hours/semester of didactic activities) 
3.1 Hours per week 	1	Of which: 3.2 course	0	3.3 seminar/laboratory	1 lab	
3.4 Total hours in the curriculum 	14	Of which: 3.5 course	0	3.6 seminar/laboratory	1	
Time allotment:	hours	
Learning using manual, course support, bibliography, course notes	14	
Additional documentation (in libraries, on electronic platforms, field documentation) 	14	
Preparation for seminars/labs, homework, papers, portfolios and essays	14	
Tutorship	5	
Evaluations	14	
Other activities: ..................	0	
3.7 Total individual study hours 	61	
3.8 Total hours per semester	75	
3.9 Number of ECTS credits	3	

4. Prerequisites (if necessary)
4.1. curriculum	•		
4.2. competencies	•		

5. Conditions (if necessary)
5.1. for the course	•		
5.2.  for the seminar /lab activities	•		

6. Specific competencies acquired 
Professional competencies	•	Knowledge, understanding and use of basic computer science concepts.
•	Ability to independently work to solve medium problems.	
Transversal competencies	•	Better programming skills: debugging and compile time error correction .	

7. Objectives of the discipline (outcome of the acquired competencies)
7.1 General objective of the discipline
	•	Be able to understand distributed software concepts and problems
•	Improved design and programming skills
•	To improve programming skills for developing a correct program  by following step by step the development phases: specification, design, implementation, verification and documentation validation. The end result should be a complete documentation.
•	The focus is on writing a complete and clear documentation on time. 	
7.2 Specific objective of the discipline
	•	The development of a complete small-size software system following the phases: specification, design, implementation, each phase verification (inspection and  testing);
•	Elaborating  development documentation  (in parallel with each phase), for each phase;
•	Writing user guide documentation.	

8. Content
8.1 Course	Teaching methods	Remarks	
Bibliography	
8.2 Laboratory	Teaching methods	Remarks	
1. Problem definition and specification. Specification inspection 
      Inspectarea specificarii.		Discussions, explanations	•	Problem documentation – Problem statement in natural language (without any reference to design and/or implementation). Students have to specify what the program should do, not how it should do it. 
•	Input and output persist data will be handed in in text file (output data formatting is compulsory) Eg. The list of persons living in a block or the list of employees. 
•	The problem statement will be handed in during first lab. 	
2. Project design documentation. Design inspection                           	Discussions, explanations	•	Clear specification of the problem. It must contain input data specification and results (output data) specification. The semantics of each input or output data and the preconditions and postconditions must also be specified. 
•	Problem specification must contain:
-program functionalities.
-input data
-necessary computation
-results or output data
-needed documents and reports
-data dimensions.
	
3. Implementation. Source code inspection.	Discussions, explanations	•	Design documentation will contain:
- all the necessary diagrams
- each subalgorithm specification, explaining the meaning of each parameter.
- each subalgorithm in Pseudocode	
4. Program testing.	Discussions, explanations	Source code (in electronic format)
The source code must contain enough comments for internal structure documentation. It must be properly indented, clear and easy to understand by other people. 
	
5. Testing documentation. Debugging and error correction.		Discussions, explanations	Testing documentation must contain test data for each used subalgorithm and for each functionality. Test cases creation will be performend using both black-box and white-box testing. 	
6. User guide documentation. Program validation. 	Discussions, explanations	User guide documentation (in electronic format).
	
7. Project hand-in and evaluation			
Bibliography
. Gamma E, Helm R, Johnson R, Vlisides J (1994): Design Patterns: elements of reusable object-oriented software, Addison Wesley.
2. Jacobson I, Booch G, Rumbaugh J (1998): The Unified Software Development Process. Addison Wesley Longman. ISBN 0-201-57169-2.
3. Knuth D.E. (1987) A számítógép-programozás muvészete, V. 1: Alapveto algoritmusok, Muszaki Könyvkiadó, (Simonovits Miklós), 654pp.
4. Knuth D.E. (1987) A számítógép-programozás muvészete, V. 2: Szeminumerikus algoritmusok, Muszaki Könyvkiadó, (Simonovits Miklós), 690pp.
5. Iványi A (szerk) (2004) Informatikai Algoritmusok, ELTE Eötvös Kiadó. (http://compalg.inf.elte.hu/~tony/Elektronikus/Informatikai/Infalg1E.pdf)
6. Cormen T.H, Leiserson C.E, Rivest R.L (2001) Algoritmusok. Harmadik kiadás. Muszaki Könyvkiadó, Budapest.
7. Horváth Z, Fóthi Á (2005) Bevezetés a programozásba, ELTE elektronikus tankönyv (http://people.inf.elte.hu/ekonyvtar/)
8. Frentiu M, Lazar I (2000) Bazele Programarii: Proiectarea Algoritmilor, 2000, Ed. Univ. Petru Maior, 184 pp.	

9. Corroborating the content of the discipline with the expectations of the epistemic community, professional associations and representative employers within the field of the program

•	Students will understand the development phases of a software system and they will gain the abilities to perform the activities related to each phase of the development cycle. 	

10. Evaluation
Type of activity	10.1 Evaluation criteria	10.2 Evaluation methods	10.3 Share in the grade (%)	
10.4 Course				
10.4 Seminar/laboratory	A mark for evaluating the activity during semester that is based on each phase mentioned above (Mark A). 
	Each not delivered phase will be considered as having mark 1. If a phases is not delivered on time, the mark will be decreased by the number of weeks delayed. 
-Documentation for each development phase 	33.3	
	For the correctness and completeness of the software system, at its validation a second mark will be given (mark V). This mark will consider also the documentation done so far and the consistency between the specification and the final product. 
	-Documentation for each phase
-Consistency between final product and documentation. 	33.3	
	In the last wek each student will deliver all the written documentation. The documentation, the problem statement and the user guide (in electronic format) will be delivered to the course coordinator that will evaluate them (mark D). Delays are not accepted and any missing documentation will affect the subject pass. 
		33.3	
				
10.6 Minimum performance standards	
•	The students have to deliver a working software system that satisfies the clients requirements. 
•	In order the pass the course the student have to obtain at least mark 5 (from a scale from 1 to 10) for each mark considered for evaluation (A, V and D).

Date		Signature of course coordinator 		Signature of seminar coordinator
..................						Lect. PhD. Grigoreta Cojocar
Date of approval  					  Signature of the head of department	
...........................................					Prof.  PhD. Bazil Parv