. Page 25.1131.1 c American Society for Engineering Education, 2012 Revisions to Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering1. Introduction Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs inSoftware Engineering (SE 2004)1 is one volume in a set of computing curricula adopted andsupported by the ACM and the IEEE Computer Society. In order to keep the softwareengineering guidelines up to date the two professional societies established a review project inearly 2011. This paper describes that review effort and plans to revise the guidelines over thenext year and a half.2. Project organization The charge for
summarizescurrent progress and plans for the NSF project. Finally, it discusses student reactions, lessonslearned, and future directions.IntroductionTo improve student learning, enthusiasm, and retention, especially in science, technology,engineering, and mathematics (STEM) areas, educators have developed a wide variety of activelearning approaches to engage students, enhance learning, and emphasize attitudes and skills inaddition to knowledge; a few reports are summarized below. Baldwin2 described experiences,benefits, and pitfalls with discovery learning, which broadly refers to learning through self-teaching. McConnell17 discussed active and collaborative learning (ACL), a set of ACLactivities, associated risks and ways of addressing them
, anddevelop problem solving skills. Although the use of case studies in education has shown success in theabove mentioned disciplines, it is yet to be adopted in any significant way in the computing education.Although many computing and engineering textbooks provide case studies to illustrate concepts andtechniques, and there are various case study websites (e.g., http://sciencecases.lib.buffalo.edu/cs/,http://www.afit.edu/cse/cases.cfm), they often lack the following:• Realistic artifacts (often space or intellectual property concerns do not allow one to provide a complete engineering artifact such as a design document or a project plan)• Completeness (most are focused on some part of engineering practice, or on a single course)• Ability to
theentire test set. For prioritization, test cases are ranked based on a suitable metric (e.g., based onthe statement coverage of each test).This module also discusses the potential weakness of using minimization and prioritization forselecting regression tests. Additional test selection techniques for regression testing are alsocovered. Module 3 is most suitable for inclusion in the advanced programming course (e.g., CS4336) and the undergraduate testing course (e.g., CS/SE 4367).Module 4 – Quality Software Testing Documentation: Leave yourself more than a noteThis module covers software testing documentation standards and the importance of creatingquality documents. Students are taught about the documents such as test plans, test requirements
andpractice for software development and covers software requirements, analysis, softwarearchitecture and detailed design.CS 5374 Software Verification and Validation. This course introduces how to implementeffective test and measurement programs as well as how to apply this knowledge to theproduction of low-defect software.IE 5329 Project Management. This course covers technical, organizational, andpersonnel project management examination including planning, estimating, budgeting,scheduling, resources management, and control. It also includes risk analysis andmanagement using software for project performance evaluation.IE 5320 Systems Theory. This course examines theoretical foundations of general systemstheory applied to engineering and
scope, changes in design, and defects.5. Assess risk, probability of the risk, triggers and formulate contingency plans.6. Construct a statement of work with appropriate acceptance criteria.7. Describe the relationship between Testing and Quality Assurance.8. Describe the Quality assurance practices appropriate for each part of the development life cycle.9. Create user based requirements and engineering requirements.10. Describe traceability and be able to map a requirement through all project artifacts.11. Describe different modeling techniques and where they apply.12. Describe the different architectural views and assign them to parts of the life-cycle.13. Asses risk and develop risk management plans
individualteam member. There exist at the personal level core software engineering competencies that needto be cultivated to allow an individual to fulfill their potential as an effective team contributor.Students in a course introducing team based software engineering typically possess adequateintroductory programming skills, but often lack other competencies required to execute asoftware project successfully. Students have rarely been introduced to concepts beyondprogramming, such as estimation and planning, continuous integration, detailed design,debugging and unit testing. Part of being a software engineer is the knowledge of multipleprogramming languages and tools; without such knowledge it is impossible to make intelligentengineering
engineering portion of the survey. SE1 I can list the high-level phases that comprise a software project in a real-world environment. SE2 I am comfortable that I could participate in the planning and development of a real-world software project. SE3 I can list the steps in the software process we used in HFOSS project. SE4 I can use a software process to develop an HFOSS project. SE5 I am sure that I can actively participate in an HFOSS community to develop a software project. SE6 I have gained some confidence in collaborating with professionals from a variety of locations and cultures. SE7 I can describe the impact of project complexity on the approaches used to develop software. SE8 I can describe the impact of
both governmental and non-governmental organizations. Acharya has a M.Eng. in computer technology and a D.Eng. in computer science and information management with a concentration in knowledge dis- covery, both from the Asian Institute of Technology in Thailand. His teaching involvement and research interests are in the areas of software engineering and development (verification and validation) and enter- prise resource planning. He also has interest in learning objectives-based education material design and development. Acharya is a co-author of ”Discrete Mathematics Applications for Information Systems Professionals,” 2nd Ed., Prentice Hall. He is a life member of Nepal Engineering Association and is also a member
(based on a web-questionnaire) was that about a half of the students were planning to use the wiki to preparefor the exam and also planned to use the material produced for the wiki later for their stud-ies. On the down side, they admitted that plagiarism and cheating is always a concern whencontent is shared. Their work also differs from our in that their personal learning diaries arepublic, whereas ours are private.Gillet et al. 4 describes a collaborative web-based experimentation environment introduced atthe Ecole Polytechnique Fédérale de Lausanne. A key component of this environment is theeJournal, a Web service that enables the collection and sharing of preparatory notes and ex-perimental results with both peers and teaching assistants. It
beginning to critically analyze the problem scope. The team members thenshare their ideas for use cases. A vote commences to determine the direction that will befollowed. Now that the team has agreed upon direction, the scope of this direction is refinedwhere detail is added to use cases for phase 2 and a design class diagram is the output of phase 3. Page 25.106.4In the remaining four stages of the CCM the team would be translating the plan into a detaileddesign, implementing the design, testing, and finally delivering the solution. Working throughthe first two stages of the CCM, the team is able to conceptualize the problem resulting in a
, why are SCRUM and Agile methods not connected? RiskManagement is more than just a Process Component based on contingency planning. SoftwareMaintenance does not “ensure correct functionality” for Testing, and so on. One could look atthe sub-graphs here and like the structure, but would need to evaluate semantically to see if thosestructures made sense.4 Assessment Protocol and ResultsOur assessment protocol was as follows: Page 25.213.7Figure 3. Software Process and Project Management concept map1. Expert evaluators were recruited from the software engineering faculty.2. The evaluators were given a short pre-briefing that included reviewing the
outside of the application domain sequence. Thus, for any givenoffering of one of these courses, more than half of the students may be taking that course as atechnical elective without any plan of taking the other two courses in the sequence. Thisproblem is magnified even more by the fact that students of both the software engineering andcomputer engineering programs routinely take these courses as technical electives. This makes itmore challenging to offer these courses in a neutral manner.Scheduling is also an issue with these courses. Because of the small size of the programs, thesecourses are only offered every other year, resulting in a mixture of both junior and seniorstudents taking the courses. This results in significant differences in
validation) and enter- prise resource planning. He also has interest in learning objectives-based education material design and development. Acharya is a co-author of ”Discrete Mathematics Applications for Information Systems Professionals,” 2nd Ed., Prentice Hall. He is a life member of Nepal Engineering Association and is also a member of ASEE and ACM. Acharya is a recipient of the ”Mahendra Vidya Bhusak” a prestigious medal awarded by the Government of Nepal for academic excellence. He is a member of the Program Committee of WMSCI, MEI, CCCT, EEET, ISAS, AG, KGMC, and IMCIC and is also a member of the Editorial Advisory Board of the Journal of Systemics, Cybernetics, and Informatics of the International Institute