Displaying items by tag: student project

"Software Engineering" is a course taught at Faculty of Electronics, Telecommunications and Informatics, Gdańsk University of Technology, Poland. The course belongs to the core part of teaching programme for undergraduate engineering studies in Informatics and is obligatory for all Informatics students.

The course is focused on introducing students to the aspects of industrial software development: large-scale systems and their software development projects, compliance to requirements of a specific customer, business goals driving requirements and design, a required level of quality to be assured, deployment and long-term maintenance of systems. It consists of lectures and laboratory sessions.

The lecture presents the key areas of software development: planning and management, requirements engineering, analysis and design, coding, testing, deployment and maintenance, tool support, team working. It also outlines several software lifecycle models and software development methodologies.

The laboratory has a much more narrow scope – it is focused on practical learning of object-oriented analysis and design. The solutions used for the lab include Unified Modeling Language as a modeling notation and SparxSystems Enterprise Architect  (EA) as a CASE tool.

Enterprise Architect was first introduced in 2009 thanks to the Academic Site Licence granted by SparxSystems, earlier another CASE tool had been used. There were several reasons for this choice:

  1. A dedicated functionality related to OO analysis and design, including consistency checks, automated transformations, source code generation and other features;
  2. A relatively lightweight tool in terms of both: features available (the user interface does not scare students with a multitude of superfluous features) and infrastructure required (there is no need to maintain shared repositories, configure access, monitor server’s availability etc. – it is sufficient to install EA on particular workstations and the model, included in a single *.eap(x) file, can simply be transferred from one workstation to another);
  3. A popularity of EA in Polish IT industry – our insight in the local industry indicated that it is the most commonly used modelling tool by business/system analysts and we intend to familiarize students with the tools they are likely to encounter in their professional career.

Students work in 3-person teams, thus a teamwork aspect is also introduced as part of the course. Each team comes up with a proposal of the topic they intend to work on. Definition of the topic includes the idea of an IT system and characteristic of a customer organization that procures such dedicated system in order to support its business processes. From the point of view of course’s goals it is very important that the students learn to analyze the customer organization (and more widely considered problem domain) and to derive system’s scope and requirements from such analysis. It is also important that the customer organization is something more complex than e.g. sole proprietorship, so multiple stakeholders (with distinct needs and points of view) and multiple users (with various features required from the system) can be identified. Students are encouraged to choose topics they have some domain knowledge about (e.g. from their part time jobs, from family business etc.).

Students’ laboratory assignments mostly concern developing models representing system requirements and design decisions. Their tasks do not require the full scope of EA functionality e.g. features related to testing, maintenance, project management etc., but they make quite a comprehensive use of functionality dedicated to analytical and design modeling. The laboratory consists of the following assignments:

  1. System Vision document – A textual report describing the customer organization, business goals, stakeholders, users and their specifics and finally requirements for the IT system divided into functional requirements, non-functional (quality) requirements and constraints.
  2. Use case model – System use cases (representing IT system’s functionality) visualized on a use diagram and structured descriptions of at least 20 use cases.
  3. Class model – an analytical class diagram including all information resources that are necessary to deliver functionality described in use cases.
  4. Dynamic model – several behavioral diagrams including sequence diagrams, collaboration diagram, activity diagram and state machine diagram.
  5. Elements of design – selected activities belonging to system design e.g. definition and modeling of system’s logical and physical architecture, database design, user interface design, sample code generation.

Consistency between subsequent assignments is considered as very important and reflected in grades given by lecturers (e.g. use cases should refine functional requirements from Vision document, sequence diagrams should conform to use case descriptions and include objects of classes defined in class diagram etc.). This form of lab activities allows students to deal with  a non-trivial model consisting of several diagrams and documents (instead of simple examples of UML constructs), to experience how particular diagrams and other parts of the model influence each other, and finally to deal with various areas/phases of software engineering (e.g. starting from business goals and generic requirements, finishing with UI sketches outlining how such requirements will be fulfilled). The assignments end with design activities, the scope of the lab does not include developing the code of such system.

As already mentioned, the course has been taught since many years for all Informatics students. Later it was also made part of the programme for Informatics in Medicine (one of streams of Biomedical Engineering field of study). Since last year, the course is also taught for Data Engineering field of study (and language of this course is English, contrary to Informatics and Biomedical Engineering courses that are taught in Polish).

Since introduction of Enterprise Architect in 2009, another edition of Software Engineering course was run each year. The number of students differed significantly between particular editions (from about 180 to over 270), in total over 2300 full-time undergraduate students participated in the course and used EA for their lab assignments. In addition, a similar course has been run at part-time undergraduate studies with about 400 participants in recent years. As result, the total number of future engineers trained in OO analysis and design as well as using EA, is over 2700 and will continue to increase, as we do not plan to switch to another CASE tool.

A number of example results of students’ work are provided as attachments. All of them are in English. The PDF documents are System Vision reports. The EAP files include results of assignments 2-4. Results of assignment 5 (elements of design) are not included as they span several files with source code, UI sketches etc.).

Published in Case Studies

 

Introduction (See attachment for full article)

 

For the past several years I’ve enjoyed a mostly informal association with the University of Southern California Center for Systems and Software Engineering (USC CSSE).  I was on-staff at USC a few years ago teaching SysML and Model Based Systems Engineering, but for the last few years I’ve been mentoring Computer Science grad students in two Masters courses: CS577 Software Engineering and CS590 Directed Research.   The Directed Research (DR) course is basically a mechanism for students who are about to graduate from the Masters program but are one or two units short of the required number to pick them up by participating in a project with a mentor from industry (that would be me).   Students are expected to work 5 hours per week per unit.  

Teaching at USC is fun (I graduated from SC back in ancient times), gives me an opportunity to work with a lot of bright young software engineers, to stay current on new technology (in particular cloud-connected mobile app development) and also gives me an excuse to work with Prof. Boehm (author of Balancing Agility and Discipline among numerous other titles), who has happily taken an interest in some of my ideas related to improving productivity by innovating better software processes and allowing me to test my ideas out with USC grad students.  

This process work has included the development of the Resilient Agile process, an attempt to develop a better agile methodology which started out as an experiment called Massively Parallel Use Case Modeling that we did with the CS577 class a few years ago where we developed a complete location-based advertising system by handing one use case to each of 47 grad students and having each student develop their use case independently.  

This semester I’m working with a group of 15 Masters students, mostly taking a single unit of  DR.  One student is taking two units, so my team has an effective time budget of 80 student hours per week.  Although the semester at USC is 16 weeks long, by the time the student teams get formed, and with midterms and finals, we’ve got about 12 usable weeks of student time.  So it works out to a time budget of roughly 1000 student hours (that’s about half-a-person-year at 40 hours a week) over a 3 month schedule. 

Because I like challenges, we’re attempting a “crowdsouced bad driver reporting system” this semester, and because we need to be really productive, we’re using Enterprise Architect to coordinate all of the student homework.  This is the first article in a series that will describe our progress.

Are we crazy to think that we can get this system built in 3 months with a total of half-a-person-year of developer time?  Stay tuned for our next article to see how we’re doing.

Read Part 2 of this Case Study

 

Published in Case Studies