Practice in Software Engineering Course: "What and How to Study"
Authors: Yu A Solyanik; M. Vladymyrova; Iryna Zarets’ka; G. Zholtkevych
Year: 2011

The goal of this paper is to share the experience of V. N. Karazin Kharkiv National University in Software Engineering training, especially in organizing students’ practical work so that they gain competences required by modern software industry based on world standards. As software development became now comprehensive industry there is strong demand for highly qualified specialists all over the world. As any industry it is based on standards for products as well as for processes. So any university graduate planning to work in this industry should know these standards and be able to work with them including tailoring to the concrete situation. It is especially true for the graduates majoring in Computer Science (CS). Usually these knowledge and skills are taught in the course of Software Engineering (SE) which is adjourned to the senior years when all the fundamental concepts of CS and technological skills have been already gained. Unfortunately all manuals on SE studies including Computing Curricula present only core topics to discuss and learn but no hints on how to organize practice with visible results of students’ growing as specialists just ready for industrial work. It is up to the University to decide the ways to develop such competences in graduates. Our university developed its own approach to provide necessary competencies so the goal of this paper is to share our views and experience with other universities as well as to have feedback as to advantages and disadvantages of our approach. There are several definitions of SE. Let us take this one: ”Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use” [1]. Another one tells that SE encompasses knowledge, methods and tools for defining software requirements and performing software design, software construction, software testing and maintenance tasks. Anyway as any engineering discipline SE is regulated by number of normative documents and standards. Among world leading standardization organizations in this field are ISO, IEC, IEEE, ESA. Their standards concerning SE cover all the parts of this discipline. It is just natural to build the subject of SE on the foundation of the normative documents and standards. Studying the majority of standards 128 Yu. Solyanik, M. Vladymyrova, I. Zarets’ka, G. Zholtkevych in the course of SE we base our practice mostly on the ESA standards [2] as they usually include all the information from similar standards of other organizations but are more verified as they deal with critical software. According to these standards we divide Software Life Cycle (SLC) onto six phases which are User Requirements phase (UR), Software Requirements phase (SR), Architectural Design phase (AD), Detailed Design phase (DD), Transfer phase (TR) and Operation and Maintenance phase (OM). It is essential to teach SE in such a way that students could go through each phase of SLC performing its tasks and preparing corresponding artifacts and documents strictly in compliance with the standards. Knowing as many standards as time allows and being able to apply them practically will make it possible for students to perform agile tailoring of them depending on company policy and concrete type of project when working in industry. The whole process of studying looks like this. According to SWEBOK [3] SE discipline consists of two big areas which are Software product engineering and Software management. In fact we have these parts in two different courses but they go in parallel with common ideas and projects to work on. Both courses are taught to the graduate students (fifth year) so the main goal of both of them is to systemize and generalize all the knowledge and skills gained by students before via series of conceptual lectures made by students themselves in form of presentation and practical work of real industrial level. So we organize semester long business game on SE (both parts) with students working in teams on real projects and playing different roles during the process of development. In fact they all go through being business analysts, system analysts, system architects, quality assurance personnel, team leaders, project managers and technical writers. Moreover they usually work on projects that are needed by University subdivisions or have real customers and timescales with several students of younger ages (usually fourth and third years of study) to their subordination making exploratory and experimental prototyping, coding, unit and integration testing, etc., which can be estimated for them as course work or even bachelor project. This heightens the responsibility of graduate students not only for the projects to be done in time but for undergraduates to have good marks under their leadership not to mention their own marks on the SE subjects. All graduate students are divided into teams consisting usually of 3 to 4 graduate students (depending on the project scope) plus 2 to 3 undergraduates. Each team works on a separate project but reviews the project of its peer team. The process of peer reviewing is not less important than working on their own project as it allows students to see mistakes and blunders as well as successful features more clearly. All the steps, activities and solutions are thoroughly documented and reviewed which at the end gives the full picture of students’ progress and results. The topics of conceptual lectures in SE are presented in the table. In fact all the key areas and units are well presented in SWEBOK [3], PMBOK [4] and Computing Curricula [5, 6] so we only packed them into topics and added some modern technological aspects [7]. In fact we use a lot of standards and literature in this course, it will take several pages to present all of them, so we put only Practice in Software Engineering course: ”what and how to study” 129 those we directly refer to in this paper into the list of literature below. Software Product Engineering Software Management Topic Hours Topic Hours Taxonomy of standards in SE 1 State of the art in SE and Software Management. Software Project Management, Software Quality Management, Software Configuration Management. Four Ps: Project, Product, Process, Personnel 2 SLC concepts and models (including classical and modern ones like Agile, SCRUM, KANBAN, etc.) 2 Project goals. Project processes scheme. Six management processes. Business-planning of the project 1 User requirements elicitation methods, tools and artifacts 2 Organizational management. 2 Software requirements specification methods, tools and artifacts 2 Personnel and project environment management. General information about supporting processes. Communication management 2 System models, types and classification 2 Planning. Standards of planning. Different representations of the plan (Gant diagrams, network planning, etc.). Creating the plan. Diagrams analysis. Critical path, critical chain. Survey of tools SPMP 4 UML 2.x, history, development, usage 3 Infrastructure of planning: database of processes, base line of process stability, processes’ assets. Methods of possibilities evaluation (PSP, TSP, CMM) 1 Formal methods of requirements specification 2 Software Management. Configuration. Standards, basic concepts, methods, tools SCMP 4 Quality of software, metrics of quality 2 Software size metrics. Methods of data collection. Software size evaluation 4 130 Yu. Solyanik, M. Vladymyrova, I. Zarets’ka, G. Zholtkevych Software Product Engineering Software Management Topic Hours Topic Hours Software architecture, architectural styles and patterns, POSA, MDA, SOA 4 Software cost evaluation. Standards, models (COCOMO,COCOMO2, SLIM, etc), tools 4 Architectural design processes, methods, tools and artifacts 2 Risks. Uncertainties. Standards. Risk management and control. Quantitative and qualitative risk analysis. Models, methods, tools. Risks planning 4 Verification and validation of software, methods, tools and artifacts 4 Quality Management. General principles. Product quality. Quality Assurance (QA) organization: organizational structure of the project. SQMP 4 Detailed design processes, methods, tools and artifacts 2 Software reliability evaluation 3 Transfer, operation and maintenance processes, methods, tools and artifacts 2 Project closing, analysis and summaries 1 Now about the practical work. We prepare a number of real projects with real customers and timescales (usually semester long to develop and further to continue coding, testing and maintaining by undergraduates from the corresponding team). After teams were formed and projects selected by teams they prepare vision documents in standard form while several first lectures acquaint them with the main concepts and activities to follow. Then they proceed with the projects going iteratively through each phase of SLC. The first phase UR one takes usually 3 to 4 weeks which is longer than needed because at this time students are not yet well immersed into subject. They work directly with customers and domain experts, prepare questionnaires and make surveys to define project scope and boundaries, assess operational environment, determine users’ roles, and elicit user requirements at most thoroughness and completeness. Sometimes exploratory prototyping is needed (usually made by undergraduate members of a team). Then it takes time to learn standards and prepare the draft version of the first full document in standard form which is URD (User Requirements Document) with all requirements identified and attributed and status sheet attached. This version is reviewed by peer team and all the discrepancies found are documented and discussed during the review meeting. Then several iterations with corrected URDs and updated status sheets follow until the final version is approved and signed by both parts. At the same time the acceptance test