Jun 30, 2005 - software developer company. While students are educated theoretically in the colleges, companies are desired to hire well qualified, skilful, ...
1
Applied Software Engineering Education Cihan Varol and Coskun Bayrak University of Arkansas at Little Rock, Computer Science Department 2801 S. University Avenue, Little Rock, AR 72204 Tel: (501) 569-8137, Fax: (501) 569-8144 E-mail: cxvarol | cxbayrak @ualr.edu Abstract— If we are to consider evaluating the available workforce under the spectrums of time, cost, and reliability, the theoretical teaching of software engineering fundamentals is not sufficient to provide the skills and knowledge expectations of the employers. Besides the specialized knowledge, the non-technical skills such as the communication ability within the group for partitioning, assigning, and monitoring task progress are required as part of the background. However, these skills are generally omitted while teaching software engineering due to lack of time, environment, and/or resources. Since traditional lectures are lacking of practical ways of creating software, the focus of this research is to present our experiments during a clientsponsored project in an applied classroom environment at the University of Arkansas at Little Rock (UALR). Our goal is to provide not only the differences between the theoretical and practical education but also the impact of a real client and the vital considerations and conditions taken by the development team in order to prevent failure in the project are expressed. Finally, to measure the outcome of the applied teaching and conduct future enhancements, a pre and post-knowledge assessment were conducted. Index Terms— Client-Sponsored Project, Focus Group, Software Engineering Education, Software Management, Software Requirements INTRODUCTION
A
s technology is improving so fast in the new
millennium, software systems, and the software architectures have become essential part of the life. Companies are moving from manual labor work to automated systems in order to make the process much cheaper and easier. Software developers have been educated in traditional ways. While most of them taking an undergraduate or graduate course from the colleges, some others are educated with shortterm courses or personal initiative in learning new techniques. Because of the education system used in the environment, most of software engineering courses in colleges has not produced supply and quality of developers needed to satisfy the growing demand. Applying teacher dominated education system in the classroom forces the students to memorize the course topics without knowing the real impact of the outlined information. Moreover, not being able to work on a client sponsored problem led the students to face with real-life software engineering tasks while they are having a job at
software developer company. While students are educated theoretically in the colleges, companies are desired to hire well qualified, skilful, dedicated and real-life project experienced candidates to join their team because students need to experience the stress and adversity of working in a real-life project [1]. Because of the fact that is expressed, student oriented education system and the real-life software engineering development project are the main differences between most of the other universities and University of Arkansas at Little Rock (UALR). At UALR, software engineering courses are offered as 3 hours of lecture per week. Starting from the requirements engineering to software testing techniques, only the fundamentals of the design and development steps were taught by the instructor. Students are encouraged and expected to learn the details of the topics by researching them and applying them in the project. Also, relevant homework assignments are carefully selected and given to students regarding the related topics, so that the fundamental principles are clearly understood and applied throughout the project development phases [1]. BACKGROUND OF THE PROJECT The project which the students worked was sponsored by Acxiom Corporation which aims to implement a design to extract the most relevant information from the system based on the costumer expectations. Cleaning the data of the customers and producing the desired results require a different set of tools and sequences in which these tools are applied to determine the final outcome. Not only had the selection of this sequence, but also the freeformatted costumer input files are the important part of the information retrieval process. Moreover lack of information and the complexity of the system lead the students to face with a challenging project. The sponsored company of the project was using Data Administrators (DA) to provide the results from costumer data. However, manually specified flows have several problems [2]. They are error-prone; Some flow may be less optimized than the others; Different flows may be provided for the same job by the DAs; Different Associates may not know to reuse past solutions developed by other DAs; and
2
Manual flow specification process is labor-intensive. It can take a significant amount of time while providing the results. The company wanted to automate the selection of the flow, since automating the selection of this sequence improves the quality of service, making the process less labor intensive and less time consuming. Workflow or business process modeling can be divided into a number of aspects, including structural, informational, temporal, transactional, and functional [3]. Traditionally, workflow modeling has focused on structural aspects of processes, mainly indicating the order of execution of the component activities in the process to satisfy users’ expectations. A large number of proposals for process specification exist such as dependency information; fieldbased mapping, each with its own flavor of semantic richness; expresses ability levels; and particular grammar. In this project, with a given set of fields which act as input data and another set of required output fields, developing a chain of operators which would transform the given input data set into the required output data set is called flow generation. In other words, flow generation is the sequence of the operators that provides the desired output. Most of the operators consist of two functional structures-Fields and Parameters (Figure 1). Fields can be categorized into two sub-selections. Output Field is the produced results or information from the operator; Input Field of an operator accepts the previous Operators’ output fields as an input and runs its functions with given input fields. Parameters are the specifications of the operators which need to be assigned to a value. However, finding all parameters and all input and output fields in an operator is not possible. Some of them are lack of input fields; some others don’t have parameters. Also, trying to match input and output fields to find the relationships between inputs and outputs is not possible due to the high amount of unknown field names. Operator
Parameters
Fields
Input Fields
Output Fields
Fig. 1. Content of an Operator
METHODOLOGY The system primarily depends on the list of input and output fields of the operators. Input fields are provided from another tool called RIIT (Records Input Identification Tool). The selection opportunity of the output fields is given to the user. All the inputs to the system (input and output fields) are provided as XML files. Apart from the input, this phase
maintains a database, which contains the information on operators such as operator names, operator IDs, their input, output fields, and their dependency knowledge. The automated system is developed based on the dependencies between the operators. The output fields of an operator invoke another operator’s input fields. In most cases, these relationships helped in finding the dependencies between the operators. However, when there is lack of information about input and output relationships, the dependencies are figured out from each operator’s purpose, previously defined flows, and information from the client side. It takes years of experiences to provide some common flows for cleaning the data. Most of the time, the new business process is provided with the common flows. Some operators are present in all these flows, while some of the others may be present in one of the common flows but not in the other flows. Therefore, operators are categorized into three subtypes based on their frequency of usage in the flows. The first one was termed as “compulsory”; the, second group as “optional”; and the last one as “esoteric.” Compulsory operators are always present at the beginning of the flow, which acts as the beginning state; optional ones are used to satisfy other business requirements, which can only act with compulsory operators. Esoteric ones are used only when required to process the states for any specific use. Dividing the operators into three different categories based on the common flows saved time while providing the workflow. For instance, if such jobs require using only compulsory operators, there is no need to find the flow. This separation not only saved time, but it also raised a flag to the categorization concept of the operators. Businesses can demand money based on the operator’s category. Moreover, all compulsory operators’ most frequently-used properties can be combined in one operator, which will produce results more efficiently. Given an input state and goal state to the system (Figure 2), the workflow needs to be produced. The flow finding algorithm follows the backward chaining approach and is developed based on the classification of the operators. Because the objective is goal oriented, the backward chaining algorithm developed is satisfactory in finding the workflows. It saves time by not searching irrelevant paths while searching the flow. In backward chaining, including all parent operators is a mandatory task, and they are part of the flow. However, in forward chaining, child operators need to be searched to satisfy the goal, but some children may not produce relevant information to match with the desired output. Therefore, more branches may be searched with a forward chaining algorithm, which obviously takes much more tine to provide the workflow.
3 If it is already exists in the compulsory operator array, the algorithm is automatically discards it. If it does not already exist, the compulsory operator is moved to the array DEVELOPMENT OF THE PROJECT AT UALR AND PROBLEMS
Fig. 2. Input Selection Screen
Based on the user input files, which consists of input and output fields, the assigned numbers of all the corresponding operators are extracted from the database. Since using one operator more than once is useless, duplication of the operators is avoided. Therefore, if the costumer input file covers one or more fields of a particular operator, the operator is used only once in the flow. After identifying the operators, the compulsory ones are separated and saved in an array. For each of the remaining operators, the dependency information specified in the operator database is used to determine the parent-child relationships. With using a backward chaining algorithm, the parent operators are searched in the database until all final optional or esoteric operators are dependent on compulsory ones. A real-time flow finding screenshot can be seen at Figure 3.
Fig. 3. Flow Finding Process
The dependency selection process follows the following two rules: Rule 1: If there is duplication of an operator, old entry of that operator is deleted, and current entry is retained Rule 2: If the operator under question is a compulsory operator
Communication: The communication within the group was made in three different environments. In the class environment, the fundamentals of software engineering were taught, and some time of the course allocated for project based topics. In ordinary group meetings, twice a week all students shared their findings about the project, and possible solution scenarios were discussed. The other group meeting held one day per week with the stakeholders. Students wrote all the unanswered questions to a document and asked to the client side in the meetings. The last communication bridge between he group members was the e-mail system. There were about 500 emails within the group members, and almost half of them were sent after 11 pm. In this course we did not answer the question of what was the perfect way, but students learned about the importance and difficulty of communication [4]. Education System and Institutions: The educational community itself is increasingly moving from educator oriented format to student centered style. Also in software engineering education system, real-life software engineering projects are started to being used to give better education to the students. At UALR we are offering client sponsored projects in order to accomplish our education targets. However, students often face with the choice between wellpaid software engineering job from outside and completing degrees while they are in the institutions. The faculty may find it hard to convince students to pursue their current degree without satisfying students with the course content [5]. Task distribution: It is important to take the time to find the best possible person, when assigning the staff to a particular job. Selecting of the correct candidate should not be limited only with their skills and knowledge, but also to candidates’ work ethic and his contribution with the group are the other important things that need to be considered [6]. However at the end the students not only be the experienced in their assigned task but also needs to know what is going on in the other sessions. Therefore, giving a small presentation each week within the group members will keep the other students aware of the progress of the project. Requirements Engineering: The requirements engineering process varies immensely depending on the type of application being developed, the size and culture of the companies involved, and the software acquisition processes used. For large projects in the industry, there is normally a formal requirement engineering processes in the system engineering. However for class development projects, the requirements process might consist of brainstorming sessions, and the product “requirements” might simply be a short vision statement of what the software is expected to do.
4 Preparing a document individually always influence person to think by his own and force him to be creative while writing it. Moreover, combining individual work effort after going through separate documents lead to observe different approaches and it can propagate the scope of the project unthinkable paths and add some new functional requirements to the final SRS document. After combining all requirements information in one common SRS document, although a final deadline was given to deliver the final SRS document, the group didn’t produce it on time. Submission of the SRS document delayed couple of weeks than it was scheduled. The followings are the reasons for not being able to produce the complete SRS document in time. Missing information in delivered documents (from client) Comprehension of the complex project Owner’s lack of technical background in some areas of the project Time constraints Even after producing the first SRS document, the focus areas of the project can be changed constantly. During the analysis, design or even in implementation phase, new functional requirements that need priority than the others can be discovered. Therefore, trying to obey the fundamental principle of having a “complete documentation” before advancing any further was very difficult to maintain. On the other hand, due to time constraints, waiting for the finalization of the SRS document to start the implementation may trigger the failure at the end. Therefore, a quick assessment on the project planning and resource utilization with respect to the issues identified above, lead us to consider an agile development to obtain a prototype. Based on the group’s understanding of the project and feedback collected from the client, the first demo was built. Programming: Some courses teach students the software engineering to code from scratch, rather than modifying existing programs. However, in most cases, there is no need to invent the bulb. If the project requires a database connection between the code and a database, the code can be found from the internet. Modifying existing code will not only save significant amount of time but also teach the students to read an existing code. Client Sponsored Project: The system has to be designed for the client’s expectations. However, implementers often chose solutions that match with their criteria, not the needs of the costumer, due to communication problems. Therefore, working with the client while preparing the environment, and sharing the ideas occasionally ensures to stay in correct path in respect to success of the project. Course Management: Students often believe that it is not possible to do any analysis until all the facts are in hand. Teaching them to do quick estimates of usage levels, throughputs, and showing them how this can provide early
guidance about scale and performance are important issues [5]. In most of the courses from other majors, the assignments can be given daily based and finalized before the next lecture. However, in a real-life software engineering project, it is not feasible to keep up the deadlines of the assignments with the related lecture time frame. To overcome this disadvantage and try to keep the information fresh, small assignments of the covered topics were given to the students after each chapter. With these assignments, the concepts didn’t stand as theory. Also, students had the chance to apply the theoretical knowledge into small practice fields [4]. The theoretical education system needs to replace with the applied one in software engineering curriculum. Most curricula have not kept up with practice in recognizing the role of good abstractions for software architectures in software design [7]. Educational institutes need the flexibility and the resources to react the technological changes and costumer expectations to provide the better educated candidates to fill the gap in related job fields. The curricula of Software engineering mainly depend on making assignments involving actual programming. However, these programming assignments are generally lack of the stress and fully life cycle development of a real-life SE project. Therefore, a client sponsored project will improve the outcome of the course. Moreover not only the technology but also the programming languages are renewing themselves to keep up with the current technology. Due to this reason, students need to have the experience with newly designed programming tools in the departments. Priorities of Teaching Software Engineering: Some of the course topics of SE are more important than the others. Such as spending much time while expressing the general idea and the importance of the requirements engineering rather than the reuse of the code is needed. The priorities of teaching software engineering are shown in Table 1. Table1: Priorities of Software Engineering Topics Course Topic Priorities Requirements Engineering High OO Analysis Medium OO Design High Architecture Design High Reuse No OO programming Medium Project Management High
CONCLUSION Although a significant amount of time was spent on this project, students and the leaders believe that the effort spent was worth the outcome, and worked much better than the classical software engineering teaching methodology. The experiences show that most Computer Science departments starting to offer real-life client sponsored projects in their curriculum because real tasks motivate students to success in the project. The students didn’t understand the importance of
5 the software requirements specification (SRS), analysis and design documents at the beginning. However they realized the importance of the documents in the designing and implementation phase of the project. At the end, scheduling and planning are important management issues. Missed deadlines will ultimately impact the final outcome negatively and it will be open ticket for failure. REFERENCES [1] Varol, C., Bayrak C., ”Application of Software Engineering Fundamentals: A Hands of Experience”, Unpublished manuscript submitted to The 2005 International Conference on Software Engineering Research and Practice, Las Vegas, Nevada, USA, June 2730, 2005 [2] Thompson, C. W., Li, W. N., Xiao, Z., Harris, C., Ludwig, R., “Preliminary Architecture/Design for Flow Automation Framework”, Unpublished Manuscript [3] Jablonski, S. and Bussler, C. Workflow Management: Modeling Concepts, Architectures and Implementation. London; Sydney, International Thompson Computer Press, 1996. [4] Varol, C., Bayrak C., ”Student Centered Software Engineering Education”, Global Educational Technology Symposium, Little Rock, Arkansas, USA, May 4-5, 2005 [5] M. Shaw, “Software engineering education: A roadmap,” in The Future of Software Engineering. New York: ACM, 2000, pp. 371–380. [6] K. S. White, “Software Engineering Management for Productivity and Quality” International Conference on Accelerator and Large Experimental Physics Control Systems (ICALEPCS) Proceedings, Trieste, Italy, Oct. 1999, pp 317-319 [7] D. Garland, “Software architecture: A roadmap,” in The Future of Software Engineering. New York: ACM, 2000, pp. 91–101.
