Software Engineering Grading Criteria

7/31/2019 Software Engineering Grading Criteria

1/4

Software EngineeringSSP Computer and Communication Third Year

Final Presentation and Documentation Grading Criteria

Grading Criteria

It is important that we communicate how we evaluate projects and assign grades. Project

grading is difficult, particularly since students and advisors develop a working relationship

during the project. Project grading is also very different from course grading. In a class,

correctly completing all assignments and evaluations (designed by the professor) earns a

student an A grade. However, an A project grade requires that students go beyond this

level and demonstrate originality, initiative, and creative technical skills. Students generally

feel that lots of hard work and a nicely presented report deserve an A. Most professors(including us) do not, unless there is real analysis, originality and technical depth in the total

project effort.

Listed below are some specific guidelines on how we determine project grades. Many of the

grading characteristics described below are subjective and open to some degree of

interpretation. Student attitude throughout the project can also affect how we, as advisors,

make these subjective judgments. Students often ask at the end of a project how they can

improve their grade. No project grade can be changed by last minute work; rather, only

sustained quality effort over time will result in a good grade.

A (45-50): This grade represents a consistently excellent effort that exceeds explicit project

goals. Characteristics of A work include meeting all project goals, and exceeding them inseveral areas such as development of project objectives, initiative, originality, depth of

analysis, and creativity. This grade is reserved for performance that is exceptional and thus is

not achieved easily.

B (35-45 Marks): This grade represents a consistently good effort that attains the project

goals. Characteristics of B work include doing all that was asked in a substantially correct

form; setting clear project goals, writing a clear, professionally presented report that has not

required many drafts; completing all work in a timely and satisfactory manner; demonstrating

sound analysis that includes logical interpretation of results; and working hard, consistently,

and diligently. A B grade means the group worked well and did a good, strong job.

Students should be proud of this grade.

C (25-30 Marks): This grade represents an acceptable effort that partially attains the

project goals. Characteristics of C work include meeting some but not all of the project

goals; and writing a readable but average report requiring many drafts and lots of faculty

corrections. Missing deadlines, ignoring faculty comments on report drafts are traits common

to some C projects. Students who receive this grade have fallen short of expectations in a

number of ways.

D (15-20 Marks): This grade denotes effort insufficient. Characteristics of D work

include doing very little throughout the project; repeatedly missing deadlines; turning in

substandard work; not completing assigned tasks and showing little or no initiative and

originality.

NAC (Below 15 Marks): This grade is reserved for performance that is unacceptable for

credit. It means that a students performance (or lack of it) has seriously impeded group

progress, or it has embarrassed the advisor.


2/4

At the discretion of the advisor, members of the group may receive the same or individual

grades. Thus, demonstration of individual contribution as well as group effort is important.

Note: Your Work will be graded on the Final Presentation and the Submission of previous

work during phases. Please note getting a Grade B for example does not mean you got 45,

it means you got from between 35 to 45 and it would be later changed to marks.

Documentation: 30 Marks

Note: Please take note that these guidelines are the minimum as they have been already

submitted and discussed before during the submission of every phase. And Many of you have

already exceeded these minimum requirements.

1- General Guidelines

a. Organization

i. Work must be neat and organized with proper headings in terms ofsections and subsections.

ii. Documentation must be arranged in terms of phases submitted byemail.

b. Diagrams

All diagrams must be named with proper figure numbers and names.

2- Documentation Format Guidelines

o Cover Pageo Table of Contents.o Project Proposal

o Problem Statemento Brief Statement of Expected Solution Without Technical Details

o Feasibility Studies/ Business Caseo Preliminary Findings and Analysiso Problems and Opportunitieso Business Objectives and Aimso Identification of Stakeholders.o Project Requirements and Featureso Identification of Costs and Risks

o Business Activities and Business Processeso Identification of Old Business System Activitieso Identification of any additional Sub Activitieso Correct use of symbols.o Proper Naming Conventions used.o Business Process for Business Activities correctly drawn and named.

o Use Case Diagram and Use Case Templates


3/4

o Use cases correctly named and identified with proper conventions e.g.Must start with a verb.

o Includes , Extend and Generalization relationships correctly used andidentified.

oSystem boundaries included.

o Use Case templates included for all main use cases.o Use case templates presented in clear format, easy to understand and

correctly filled.

o Collaboration Diagram/Sequence Diagramo Showing the Relationship between objectso Correctly Identifying the Boundary, Entity, Control classes.o Direction of flow clearly and correctly labeled.o Sequence of Messages between objects clearly indicated.o Message should include any parameters that were to be

submitted.

o Any Options, Alternatives, loops correctly indicated.o Class Diagram and Responsibilities

o Class Names, Attributes and Operations correctly indicated and labeledwith clear and easy to understand names.

o Relationships correctly identified and used.o State Chart Diagram

o States of object transition presented in concise and clear manner.o Implementation

In implementation section, please specify the architecture style(s) usedand why in addition to programming language/framework used and

again the reason.

Screenshots of implementation must be included with proper figurenumbers.

o Testing Sample test cases must be included.

o References Please include any citation used in references and specify source.

o Appendix Please include any sample meeting with stakeholders or any additional

work done including project schedules, WBS, risk planes or anything

else done in appendix.

Note: It is expected thatdiagrams were drawn using UML and CASE tools.

Also THERE MUST BE A CLEAR TRANSITION from use case diagram, to sequence

diagram/collaboration diagram to class diagram to implementation and it MUST BE

EVIDENT, otherwise there will be penalization.


4/4

Presentation: 20 Marks

Content

Introduction of topico Is there a clear introduction of the topic to be discussed, and subtopics? Does

the opening slide give the name of the talk and the presenters?

Organization of topic

o Is the overall topic of the appropriate scope (i.e., not too large, so the subtopicsare merely brushed over, and not too small, so the subtopics are repetitive)? Is

the larger topic broken down into well-sized, logically related subtopics?

Slides

o Are slides legible? Are they easy to read (i.e., font size; not too muchinformation per slide, or too little per slide)? Are graphs labeled? Do any

demos (clips, sounds) work?

Individual Speakers

o Is each speaker clear? Do we understand his/her subtopic? Do speakers seemrehearsed, or are there many paused, ums, uhs, etc.? Is the speed of

presentation appropriate (i.e., not too fast or slow)?

Transitions between speakers

o Is the transition between speakers ordered/are new speakers/topics introduced?Coherence

o Ultimately, is this a group presentation (group is working towards a goal), or4-5 individual presentations that simply appear to be on the same topic?

Conclusion

o Does the conclusion sum up the goal that the presentation was focusing on,or did it just kind of stop? Is it prospective (that is, does it provide problems

with the theory/topic that was discussed, or does it provide future directions

for work, or unanswered questionsor is it just like the end; stop talkingnow)?

Quality

o Did the presentation show an understanding of the issues addressed? Was itinteresting, or just a list of facts?

Note:

Not adhering to the 15 Minutes time allocation will cause you to lose marks in

addition to being stopped half way.

Improper etiquette during the presentation will also result in penalization.

Not answering questions or answering question in a vague manner will also result in

penalization for that specific member and possibly entire group.

Documents

Software Engineering Grading Criteria