BACKGROUNDUndergraduate students in computer science engineering undertake a capstone project that should integrate the specific knowledge and skills acquired during their studies. The advisor assigned to supervise the process undertakes a multifaceted commitment that varies among advisors. PURPOSEThis study develops and validates an instrument, and then utilizes it to determine the different styles of supervision in computer science engineering capstone projects. DESIGN/METHODA questionnaire was developed to survey capstone project advisors at a university during the past two years. A total of 109 surveys were successfully collected. A combination of multivariate statistical methods, such as factorial and cluster analysis, was employed. RESULTSThis study distinguished seven main supervision factors: technology, arrangements, keep alive, execution, meetings, management, and reports. Then, six supervision styles were identified according to the advisor's varying degree of involvement in each factor: student alone, execution focused, global supervision, management focused, technological mentoring, and process focused. To further characterize these styles, we compared their applications focusing on the type of student, the grade obtained, the project duration, and the amount of time devoted by the advisor. CONCLUSIONWe have determined the main factors in capstone project supervision and characterized different styles of supervision according to these factors. These supervision styles can help advisors recognize ways to proceed in the supervision of capstone projects.

No abstract

No abstract

This block will depict the excerpt of the UML diagram with the elements that model the previous key elements. In addition, we provide a table, whose structure is illustrated below, that explains the representation of each key element, by means of UML elements. Additionally, we assign a green label containing a numeric identifier to each UML element, which makes it easier its location in the UML diagram. Key Element UML RationaleName of the element UML element id The fundamental reasons serving to account for the use of the UML element for modelling the key element.2/74 Mapping to PROVThis block contains the PROV template generated from the previous excerpt of UML Diagram, together with a explanation about the transformation, that is, the PROV elements, attributes, and PROV relations generated from the UML elements in the UML Diagram. We assign a numeric identifier to each PROV element that corresponds to the identifier of the UML element from which it comes from. Additionally, each relation among PROV elements appearing in the PROV template is labeled with a letter that helps link such a relation with its description. The structure used to specify this block is the following:The explanation of the mapping between UML element and PROV element. Attributes PROV ElementAttribute / Value Description PROV element id name of attribute / assigned value The description of the meaning of the attribute and its value.Note: Throughout this specification, we have included the attributes tmpl:startTime and tmpl:endTime associated with Activities because we consider such an information very useful from a provenance point of view. Nevertheless, both attributes are optional and the user is free to include them. PROV relations PROV Relation DescriptionPROV relation id Description of the relation.Note: In PROV, two relationships of the form (B, prov:used, A) and (C, prov:wasGeneratedBy, B) may be enriched with (C, prov:wasDerivedFrom, A) to express the dependency of C on A. This structure is a provenance construction called use-generate-derive triangle [3] which explicitly connects a generated prov:Entity to a used prov:Entity. In the realm of this work, it may be applied in those templates in which a prov:Entity is used by a prov:Activity, and such a prov:Activity generated another prov:Entity. However, aiming at avoiding the overburden of the PROV template explanations with information that can be inferred, we have decided to include the relation prov:wasDerivedFrom only when the context of the pattern explicitly refers to such a derivation. DiscussionIssues related to the transformation of UML to PROV. Concretely, we will focus on the explanation and justification of our transformation decisions together with alternative solutions (if any), and some questions that are likely to come up to the reader. 3/743 Index of patterns Modelled by means of UML Sequence DiagramsPattern identifier Context Page SeqP1A participant (the sender) interacts with another participant (the recipient) by calling an operation in the recipient, and then, ...

This study evaluates several aspects related to capstone projects in a computer science degree: level of advisor involvement, type of student, and type of project. We consider the points of view of students, advisors, and evaluation committees. Students claimed the level of advisor involvement to be significantly greater than that perceived by the advisors themselves. Regarding students skills, we found no significant differences between the opinions of advisors and students. And lastly, students have a significantly better opinion about their projects than advisors do.

No abstract

No abstract

No abstract