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 quali ed 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 de nitions 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 speci cation to maintaining the system
after it has gone into use" [
The whole process of studying looks like this. According to SWEBOK [
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 [
methods, tools and artifacts Software requirements speci cation methods, tools and artifacts
2 Personnel and project environment management. General information about supporting processes. Communication management 2 Planning. Standards of planning. Di erent representations of the plan (Gant diagrams, network planning, etc.). Creating the plan. Diagrams analysis. Critical path, critical chain. Survey of tools
SPMP 3 Infrastructure of planning: database of processes, base line of process stability, processes' assets. Methods of possibilities evaluation (PSP,
TSP, CMM) 2 Software Management. Con
guration. Standards, basic concepts, methods, tools
SCMP 2 Software size metrics. Methods of data collection. Software size evaluation 2 4 1 4 4 Software Product Engineering Software Management
Topic Hours Topic Hours Software architecture, archi- 4 Software cost evaluation. 4 tectural styles and patterns, Standards, models (COPOSA, MDA, SOA COMO,COCOMO2, SLIM, etc), tools Architectural design pro- 2 Risks. Uncertainties. Stan- 4 cesses, methods, tools and dards. Risk management artifacts and control. Quantitative and qualitative risk analysis.
Models, methods, tools.
Risks planning Veri cation and validation of 4 Quality Management. Gen- 4 software, methods, tools and eral principles. Product artifacts quality. Quality Assurance (QA) organization: organizational structure of the project. SQMP 2 Software reliability evalua- 3
tion 2 Project closing, analysis and 1 summaries
methods, tools and artifacts Transfer, operation and maintenance processes, methods, tools and artifacts
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 rst 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 rst 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 de ne 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 rst full document in standard form which is URD (User Requirements Document) with all requirements identi ed 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 nal version is approved and signed by both parts. At the same time the acceptance test plan is being worked out and documented.
As to the management activities students de ne their projects goals from the management point of view and elicit main processes, nd the appropriate structure of their team organization, distribute roles and write down the responsibilities of each role. They also get acquainted with the MS Project tool.
The second phase overlaps rst one and usually begins when rst URD draft is submitted for the review. Second phase usually takes the same time as rst or a little longer as it supposes analysis of the requirements and logical model construction as well as system requirements speci cation. At this time students have already studied di erent system models and software quality metrics, which facilitates the process of a logical model construction and working with both functional and non-functional requirements in quantitative form to be properly veri ed. They use various CASE tools for model construction and speci cation. At the end of this phase the Software Requirements Document (SRD) is prepared with obligatory traceability matrix attached. Again iterative process of documented peer reviewing and making changes takes place, which ends with the approval and signing of SRD.
As to the management activities this phase is dedicated to planning. Students plan their work on the project using MS Project tool, identify tasks, de ne their sequence and duration of each of them, and determine types of relations between tasks. Then they assign real terms and resources for each task, e. g. form the project's schedule and construct the critical path using MS Project tool and developing their own program to build a critical path just to compare the results. It allows them to evaluate the real duration of the project. Students also consider di erent solutions to the problem of resource overloading. At this phase the SPMP in standard form is being prepared and submitted for the review.
The third phase is the most hard for students because it requires all their previous knowledge and skills, sometimes they are compelled to learn new technologies and make exploratory prototyping to solve architectural problems usually rising from non-functional requirements and to apply appropriate architectural styles and patterns. They have to construct a physical model with detailed description of each system component, process, software module and physical node of software deployment which is not only di cult to perform but time consuming as well even using advanced CASE tools (not to mention regular returns to the previous documents). At the end of this phase the standard ADD (Architectural Design Document) is submitted for the review which also takes several iterations before nal approval.
As to the management activities this phase is dedicated to the Con guration Management. Within the frame of their project students create repository to store all the artifacts of the project, make checkouts, updates and commitments, add les and folders, assign tags and create alternative branches of development process using TortoiseCVS and TortoiseSVN tools. They also prepare Software Con guration Management Plan (SCMP) in standard form and submit it for the review. Another students' activity at this phase concerns with software cost estimation. They use Costar and USC-COCOMOII 1999.0 with CostXpert tools to estimate the cost of software for the early design model and for post-architecture. For their projects students assign the values of Scale Drivers, Cost Drivers, Function Points or SLOC, Resource Costs and make necessary calculations and reports. The SPMP draft made at the rst phase is now being improved with reference to the risk plan developed further.
The fourth phase heavily overlaps the third one as it is usually done by undergraduate members of the team and starts just as the critical architectural solutions have been made. It consists of coding, unit and integration testing with all documentation required by standards. At this time graduates begin writing PHD (Project History Document) as time goes to the end of semester. The main output document of this phase - DDD (Detailed Design Document) - takes too much time to prepare so graduates usually only supervise its preparation and as our experience shows never have time to verify it thoroughly. This is mainly the responsibility of undergraduates to nish coding and testing as well as transfer releases to customers and maintain them during the operation before provisional acceptance and after it. At this moment we try to have new younger students to learn this software to be able to maintain it.
As to the management activities this phase is dedicated to risk control and management. Students make the risk plan for their projects which includes all steps of working with risks e. g. risk identi cation, risk estimation, methods of responding to risk events and control of these responses. They use PertMaster Project Risk v7.6.0006 tool for this work. At this phase they also prepare Software Quality Management Plan (SQMP), specify and improve SCMP made at the previous phase and consider problems of management according to the plans. At the end of this phase the process of project closing is being considered, analyzed and the whole project is summarized.
Certainly the time limits and kinds of projects students develop do not allow them to go practically through all the management activities and artifacts considered in theoretical study, but even what is done gives students some management skills to be developed in their further work as no industry newcomer begins his or her career as a software project manager.
As a result our graduate students learn to work with requirements and specify them, make sound and grounded architectural solutions, carry out management activities and present all information in compliance with world standards. All that is being done in a team work with peer veri cation and audits made by teaching sta . As to the bene ts for undergraduates they learn a lot from their senior mates which is good in itself, plus get ready for analytical work next year. Sure a lot of work is done by each member of a team with all those paper artifacts being meticulously prepared according to standard forms. A lot of them might seem excessive for real middle size industrial software company using agile methods and techniques. But what we think is: it is better to master the whole process and use only parts of it than to know only some parts when it is necessary to use the whole process.