AC 2011-1690: REPORTING ON THE USE OF A SOFTWARE DEVELOP-MENT CASE STUDY IN COMPUTING CURRICULAMassood Towhidnejad, Embry-Riddle Aeronautical Univ., Daytona Beach Massood Towhidnejad is a tenure full professor of software engineering in the department of Electrical, Computer, Software and System Engineering at Embry-Riddle Aeronautical University. His teaching interests include artificial intelligence, autonomous systems, and software engineering with emphasis on software quality assurance and testing. He has been involved in research activities in the areas of software engineering, software quality assurance and testing, autonomous systems, and human factors.Thomas B Hilburn, Embry-Riddle Aeronautical Univ., Daytona
because it caused the students to review thework at an earlier time to participate. Figure 3. Domain engineering roadmap emphasizing individual contributions Table 3. Term paper topic influenced by individually- or group-led topic in classStudent Basic Topic Led Advanced Topic Led Term Paper Topic (k) on “Reusability Grace (a) Re-engineering for Reuse Metrics” (k) on “Software Product Dave (b) Measurement and Experimentation
: Student Reactions (An Experience Report)”, Proceedings of the 13th Conference on Software Engineering Education and Training, Austin, TX, USA, March 6-8, 2000, pp.169-175. [8] Moore, M. M. and Brennan, T., “Process Improvement in the Classroom,” Proceedings of the 8th SEI CSEE Conference, Lecture Notes in Computer Science, New Orleans, LA, USA, Springer, March/April 1995, pp. 123-130. [9] Moore, M. M. and Potts, C., “Learning by Doing: Goals and Experiences of Two Software Engineering Project Courses,” Proceedings of the 7th SEI CSEE Conference, Lecture Notes in Computer Science, Springer-Verlag, January 1994. [10] Naur, P. and Randell B. (eds), Software Engineering: A Report on a Conference
paper is on outcomes assessment as mandated by ABET,but we acknowledge other sources are also very important. In particular, our program alsoreceives input from a program advisory board, a college advisory board, three and five yearsurveys of graduates and our graduates’ managers, and benchmarks against other programs.OutcomesThe current software engineering outcomes, adopted in December of 2004, are: A. Foundation: Graduates shall have a strong foundation in science, mathematics, and engineering, and can apply this fundamental knowledge to software engineering tasks. B. Development: Graduates can effectively apply software engineering practice over the entire system lifecycle. This includes requirements engineering, analysis
inindustry hiring, where companies often include a short logic or programming problem as part ofthe interview process. The goal in all cases to gage how the individual works through a problemand to provide an indicator of their technical ability.Practica are given in class at the conclusion of each major topic (C with no pointers, C withpointers, Ruby, etc.). Appendix B contains a sample practicum description. We focus on shortprogramming problems that a competent engineer can complete within an hour. The problemsreflect the in-class activities and project assignment, and are submitted in stages to rewardincremental development and submission. Practica are open book, open notes, open internet – inessence, open everything except mouths. Practica turn
related and engineering programs as well. Some of the reasons for this decline is a. decline in the IT industry b. increase in outsourcing c. misconception of the incoming students that CS and SE are fields focused primarily on programming and Web design d. Incoming students focus on the job market today, which may be entirely different four years later. Student employees form a transitional workforce. Students move in and out of projects due to various reasons: graduation, transfer in and out of university/program, Page 11.318.4 or transfer in and out of research projects. The decline in enrollment makes it hard
, 2007 (Springer Science+Business Media, New York). 3. Dugan, John P., et al, Multi-Institutional Study of Leadership. International Leadership Association, November 2006, Maryland. 4. Herrington, J., et al, A Guide to Authentic e-Learning, 2014 (Routledge, London and New York). 5. Johrendt, JL., et al, A Learning Outcomes Survey of Engineering Cooperative Education Students: Preliminary Findings, 2009, Proceedings of the 2009 ASEE Annual Conference and Exposition, paper AC 2009-789, Austin, TX, USA. 6. Nelson, B. C., et al, Global channels of evidence for learning and assessment in complex game environments, 2011, British Journal of Educational Technology, 42:88-100. 7. Software Engineering
compared to Computer Science and other engineering disciplines. The data shows 29% of the programs have 25 or fewer students and 71% have 100 or fewer. • The admission requirements vary widely. Some will accept anyone with any bachelors degree and a B average while others require a computer science degree and two years of relevant experience. • There is a wide variation in the depth and breadth of SWEBOK coverage in required and semi-required (those which a student has at least a 50% chance of taking) courses. Page 13.34.7 • On average, students take 11.6 courses for their degree, 8.3 of
AC 2012-4559: PANEL SESSION: CASE STUDY TEACHING IN COM-PUTING CURRICULADr. Massood Towhidnejad, Embry-Riddle Aeronautical University, Daytona Beach Massood Towhidnejad is the Professor of Software Engineering and the Director of the NEAR Lab (http://www.near.aero/) at Embry-Riddle Aeronautical University at the Daytona Beach, Fla. He has been involved in research activities in the areas of software engineering education, software quality assurance, and testing, and autonomous systems.Dr. Salamah Salamah, Embry-Riddle Aeronautical University, Daytona BeachDr. Thomas B. Hilburn, Embry-Riddle Aeronautical University, Daytona Beach Thomas B. Hilburn is a Professor Emeritus of software engineering at Embry-Riddle
fully by means of examining all the courses offered. The process becametedious because University A, for example, had five courses to consider, University B had threecourses to consider, and so on with the others. Therefore, to establish the amount of coverage foreach topic in each category for all the courses, composite ratings were used as set out in Table 1. Horizontal View Table 1. Composite ratings + N JM TB TM TD Vertical View N N JM TB TM TD JM JM JM TB TM TD
. Bishop, “Software Security Checklist for the Software Life Cy- cle,” Proceedings of the 12th IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 2003) pp. 243-248, June 2003.[12] OWASP, A Guide for Building Secure Web Applications and Web Services, http://www.owasp.org/ documentation/guide.html, 2.0 Black Hat Edition, July 27, 2005.[13] B. Arkin, S. Stender, and G. McGraw, “Software Penetration Testing,” IEEE Security and Privacy 3(1), pp. 84-87, Jan. 2005.[14] Paros Proxy Tool, http://www.parosproxy.org/.[15] R. Anderson, “Why Cryptosystems Fail,” Proceedings of the 1st ACM Conference on Computer and Communications Security (ACMCCS 1993) pp. 215-227, 1993.[16] S
remainder of this sectionprovides a brief overview of the institutions involved in the study to provide context forunderstanding the study. Institution ID Institution Size Department Department Size A 1,500 undergrads Math & CS 25 CS and 40 Math majors 6,100 undergrads, 245 CS and IS majors B 800 grad students CS & IS 58 MIS graduate students 2,500 undergrads, 1,000 grad C students CS & IT 100 CS and IT majors D 6,100 undergrads CS 125 CS majors
. Magleby, C. D. Sorensen, B. R. Swan and D. K Anthony, “A Survey of Capstone Page 25.106.10 Engineering Courses in North America,” Journal of Engineering Education, vol. 84, no. 2, 1995, pp. 165- 17411. Newell, S, “Collaborative Learning in Engineering Design,” Journal of College Science Teaching, vol. 19, no. 6, 1990, pp. 359-362.12. Gabriele, G. A., L. T. McCloskey, and J. A. Watson, “Guidelines for Forming and Building Student Design Teams,” Proceedings, Advances in Capstone Education Conference, Brigham Young University, 1994, pp. 121-125.13. Barrett, G.V., and C.L. Thornton, “Cognitive Style Differences Between
and future plans for this research.3. Experimental SurveyTo collect feedback regarding the HPML approach, an informal experiment wasconducted using surveys with 95 undergraduate students at the University of CentralFlorida. The students were asked if they prefer such an approach, and if they think thatthis is a better approach to learning Software Engineering. The results were grouped into4 categories (shown in Figure 6) based on the students answers.Category A: Students who think that the approach is good, but prefer to be conservativein their answer until they know more about HPML, and observe an actual course taughtusing its structure.Category B: Students who valued the idea very much and hope to register for a classstructured using
Paper ID #7783Software and System Engineering Education: Commonalities and Differ-encesDr. Massood Towhidnejad, Embry-Riddle Aeronautical Univ., Daytona Beach Massood Towhidnejad is the director of NExtGeneration Applied Research Laboratory (NEAR), and a tenure full professor of software engineering in the department of Electrical, Computer, Software and System Engineering at Embry-Riddle Aeronautical University. His research and teaching interests include autonomous systems, and software and systems engineering with emphasis on software quality assurance and testing.Dr. Thomas B Hilburn, Embry-Riddle Aeronautical Univ
aspects of thesoftware artifacts produced by and the development process followed by their teams.3.3 Data collection methodsThis section describes the methods used to collect data related to the collaboration between theISD and SPM courses.3.3.1 Data Collection Methods for ISD CourseFinal grades. To quantitatively evaluate the correlation between student performance and whetherthey were on a managed team, we compared the final grades of students on managed teams withthe final grades of students on non-managed teams.End-of-semester survey. We designed two surveys. One was given to students who were on teamswith managers and the other to students who were on teams without managers. Both surveys(shown in Appendices A and B, respectively
accelerated courseAs Table 1 and 2 show, the overall correlation to regular exam scores for the regular courseremained roughly the same. However, the correlation of the predictive exam to the overallcourse grade increased from 0.33 to 0.39. In addition, the results in Table 3 show that theaccelerated course had an even greater correlation of 0.48. This shows that the questionrefinement technique discussed previously, along with the addition of new and related questions,was effective in increasing the predictive abilities of the exam. A final analysis was done usingthe same ad hoc technique that was used with the Fall 2009 data. The results of this werecombined for both versions of the course and are presented in Figure 2. Appendix B lists
need to betaken into consideration: (1) how to construct a program graph and handle compound conditionsautomatically. Compound condition consists of multiple simple conditions, e.g., (a>b) &&(b>c) contains two simple predicates a>b and b>c. Compound conditions need to be recog-nized automatically so that different paths can be derived from a program graph based on deci- Page 26.42.2sion, condition, and multi-condition coverages; (2) how to visualize program graphs. Visualizingprogram graphs is essentially a graph auto-layout problem, which arranges the positions of eachvertex and edge of a graph automatically. However
directives to the RMU team members: 1. Establish a mode of communications with the SPSU team member (email, Text, phone, Skype, etc.). 2. Study your team’s requirements in detail. 3. Communicate with your SPSU counterparts on your requirements for: a. Ambiguity b. Inconsistency c. Clarification 4. If necessary rewrite the requirement using the KISS (Keep It Simple) principle. 5. Understand and appreciate work carried out by your team.b. SRS ReviewPrior to SPSU writing their project requirements (SRS) they were given a lecture onrequirements engineering. The review process was iterative and was initiated as soon as SPSUhad prepared a SRS version 1 (V1). This SRS was
AC 2009-1603: AN ASSESSMENT STRATEGY FOR A CAPSTONE COURSE INSOFTWARE AND COMPUTER ENGINEERINGRichard Stansbury, Embry-Riddle Aeronautical UniversityMassood Towhidnejad, Embry-Riddle Aeronautical University Page 14.181.1© American Society for Engineering Education, 2009 AN ASSESSMENT STRATEGY FOR A CAPSTONE COURSE IN SOFTWARE AND COMPUTER ENGINEERING Richard Stansbury and Massood Towhidnejad Embry-Riddle Aeronautical University Daytona Beach, FL 32114 {stansbur, towhid}@erau.eduAbstract:The assessment of individual student work on team
instructors interested in migrating from general-purpose/web application basedsoftware engineering courses to mobile application-based courses. Furthermore, the paper alsoaddresses the following aspects from a classroom instruction perspective: (1) the importance ofstructured design and requirements analysis in building secure and reliable software systems, (2)the benefits and pitfalls of using XP in a classroom setting, and (3) the need to introduceconcepts important for secure and safety-critical systems into introductory software engineeringcourses.References1. M. Shaw, “Prospects for an engineering discipline of software.” Software, IEEE 7, no. 6, pp. 15-24, 1990.2. B. Boehm, “A view of 20th and 21st century software engineering.” In
8 Term Term(a) (b)Figure 1. (a) Student perception of team sizes. Each dot in the graph is labeled with the range ofteam sizes for the respective term. Most welcome were teams of size 5-8 (corresponding to thered square dots), while smaller or larger teams (corresponding to the blue circle dots) receivedless favorable ratings in the respective terms when they occurred.(b) Student perception of the incremental delivery approach. In the first two terms the approachwas recommended, while subsequently its use was required. In the graph, the lower early
for internal consistency 1.0 Text manipulation 1.0 Synchronize interactions with users 1.5 Generate output 1.0 Perform simple calculations 0.7 Perform complex calculations 2.0These weights for the functional requirements are used to calculate the sizing parameter asfollows:Total Sizing = Weight * * (log2 * )Finally, the estimated time to complete the project is calculated as Estimated time = Constant A * Total Sizing ^ Constant Bwhere ‘Constant A’ and ‘Constant B’ are to be defined by the
the anonymous reviewers, whoprovided constructive comments that improved the quality of the paper.Bibliography1. Association for Computing Machinery (ACM). Computing curricula 2001 Computer Science. http://www.acm.org/eductation/curricula.html2. Beck, K. Test-driven development by example, Addison-Wesley, 20033. Braude, E. Software engineering: an object-oriented perspective, Wiley, 20004. Bruegge, B and Dutoit, A. Object-oriented software engineering using UML, patterns, and Java, 2nd ed., Prentice Hall, 20045. Eriksson, H. et al. UML 2 Toolkit, OMG Press, 2004.6. FreeTTS 1.2. http://freetts.sourceforge.net/docs/index.php7. Gamma, E. et al. Design patterns: elements of object-orient software, Addison-Wesley, 1995.8
AC 2011-1726: USING VERTICALLY INTEGRATED PROJECT TEAMSTO INSPIRE STUDNET INTEREST IN COMPUTING CAREERSMassood Towhidnejad, Embry-Riddle Aeronautical Univ., Daytona Beach Massood Towhidnejad is a tenure full professor of software engineering in the department of Electrical, Computer, Software and System Engineering at Embry-Riddle Aeronautical University. His teaching interests include artificial intelligence, autonomous systems, and software engineering with emphasis on software quality assurance and testing. He has been involved in research activities in the areas of software engineering, software quality assurance and testing, autonomous systems, and human factors.Thomas B Hilburn, Embry-Riddle Aeronautical Univ
GSwER2009 CBOK Knowledge Areas Content 5373 5374 5329 5320 A. Ethics and Professional Conduct 1. Social, Legal, and Historical Issues SYS X X 2. Code of Ethics/Professional Conduct SYS X 3. Role of Software Eng. (SwE) Standards X B. Systems Engineering (SE) SYS 1. SE Concepts X X 2. SE Life Cycle Management X X 3. Requirements
andobjectives of the program and institution. The professional component must include: (a) oneyear of a combination of college level mathematics and basic sciences (some with experimentalexperience) appropriate to the discipline and (b) one and one-half years of engineeringtopics…”30 This appears to be clear enough, with the most important part being “appropriate tothe discipline” which, since the SEEK specifies what that knowledge is and SE2004 specifiescurricula “to help accreditation agencies… make decisions about various institutions’ programs”,the two agencies should be working together, with ABET deferring to SE2004 for what specificsubjects are appropriate to the discipline. But that doesn’t seem to be happening.Of the 13 ABET accredited
course currency is called Knowledge Gold (KG). The following rules govern the use ofcurrency in the three term sequence: 1. All students start with 0 KG at the beginning of the year. Page 22.1091.10 2. KG is tracked by the instructor for each individual in the course. It is the student responsibility to make sure KG credit is properly recorded. 3. KG will be retained across quarters. 4. KG may be obtained by: a. Completing tasks as stipulated by the instructor. b. Asking good questions. c. Chapter write-ups. d. Research into a technical area related the course topics or topics directly related to
Programs in Software Engineering" Integrated Software & Systems Engineering Curriculum Project Stevens Institute (2009)[6] Laird, L., “Strengthening the ‘Engineering’ in Software Engineering Education: A Software Engineering Bachelor of Engineering Program for the 21st Century,” submitted November 2015.[7] Gallois, B., Sheppard, K., “The Design Spine: Revision Of The Engineering Curriculum To Include A Design Experience Each Semester.” (2009) Paper presented at 1999 Annual Conference, Charlotte, North Carolina. https://peer.asee.org/755[8] Shackelford, R., Cross, J. II, Davies, G., Impagliazzo, J., Kamali, R., LeBlanc, R., Lunt, B., McGettrick, A., Sloan, R., Topi, H., “Computing Curricula 2005”, joint effort of the ACM and the
participatinginstitutions. 100% of those who responded) said their institution offer courses in Software Engineering. From this group 42% (13) offer a B.S. degree in Software Engineering, 13% (4) offer a B.S. degree in Engineering with Software Concentration, 32% (10) did not offer a B.S. degree with Software Engineering in the title, and the remaining 13% (4) offered a variety of options. Of the 13 respondents that offer a B. S. in Software Engineering 46% (6) offer this degree through their Computer Science Department. 39% (5) offer this degree through an engineering department, and 15% (2) offer this degree through departments other than computer science or engineering