software engineering

profiles3ood_55555
sd2_evaluation_form_v11.xlsx
Home>Computer Science homework help>software engineering

Project Evaluation

SD2 - countFuncLOC project Project Team:
[DATE] Developer 1:
ASSIGNMENT POINTS 35
Weight Evaluation Criteria Possible Earned
20% 1. Planning, Estimates, Summary 7 0.00
20% 2. Requirements & Design 7 0.00
20% 3. Code & Executable Program 7 0.00
20% 4. Time Log 7 0.00
20% 5. Defect Log 7 0.00
100% 35 0.00
Grammar Penalties 0.00 <----- 0 Grammatical Errors
Late Submission Penalties 0.00 <----- 0 Days Late (-10%/day after due date)
FINAL SCORE 35 0.00
EVALUATION DETAILS AND COMMENTS Please refer to the comment tabs specific to each evaluation section for full descriptions of each comment
Weight 1. Planning, Estimates, Summary 0.000 out of 7 Comments
25% Planning 0.000
Purpose/Mission/Vision
13% Time Estimate 0.000
13% Size Estimate 0.000
12% Actual Time 0.000
12% Actual Size 0.000
25% Summary/Retrospective Analysis 0.000
100%
General Planning, Estimates & Summary comments:
[General comments here]
Weight 2. Requirements & Design 0.000 out of 7 Comments
43% Requirements and Specification 0.000
14% Follows specified file naming convention 0.000
43% Design addresses Requirements 0.000
High-Level Design (HLD)
Detail Design
100%
General Requirements & Design comments:
[General comments here]
Weight 3. Code & Executable Program 0.000 out of 7 Comments
16% Complete Code Project Submission 0.000
50% Satisfies Design and Requirements 0.000
20% Standards, Structure, Organization 0.000
14% Testing 0.000
100%
General Code & Executable comments:
[General comments here]
Weight 4. Time Log 0.000 out of 7 Comments
34% All Phases Included 0.000
33% Phases in Correct Order 0.000
33% Time Logged in each Phase 0.000
100%
General Time Log comments:
[General comments here]
Weight 5. Defect Log 0.000 out of 7 Comments
20% Identified defect type 0.000
20% Identified phase injected 0.000
20% Identified phase discovered 0.000
20% Logged time to find & fix defect 0.000
20% Included description of defect 0.000
100%
General Defect Log comments:
[General comments here]

General and Time

SHORT DESCRIPTION FULL DESCRIPTION
Overall Report & Project
1 Great Work!
2 Well Done!
3 Grammar Errors Various errors (grammar, spelling, capitalization, punctuation, etc.) throughout a work product reduce its overall quality. In the “professional” [and academic] world you will be judged based on your written communication skills. Consider reviewing your written work with someone before submitting it to help you find “obvious” errors. Tutoring in writing can also help you improve your ability to convey your knowledge and ideas. The Academic Achievement Center (AAC) has free tutors to review your writing and help improve your writing skills. http://www.ltu.edu/aac/writingcenter.asp
4 Template Artifacts Detected In the final report submission REMOVE ALL of the blue text with braces from the Report Template, and where applicable replace the text with your own text. The General Comments area should be completely removed; this is information for you, but should not be included in the report submitted.
5 Embedded Images Do NOT paste images of the Logs in the report, as this has very little value. Refer to the external document for the supporting details and summarize the desired results in the report.
6 Report document incomplete There seems to be an absence of a document describing the functional specifications, planning activities and description of the problem.
7 Label all diagrams All diagrams should have a label or caption for ease of reference throughout the document, subsequent discussions, analyses, other documents, etc. Example: * Diagram caption: Figure 1 – Overall System Context Diagram * Elsewhere in the document: Figure 1 shows the overall System Context Diagram.
8
9
10
ERROR:#REF!
1 Barely on-time Submitted within 15 minutes of the cutoff time. Risky; Not much margin for error! Did you have any contingency plan?
2 Late Submission As specified in the Syllabus, assignments are due by the beginning of class on the due date.
3 Very Late Submissions later then 24 hours will be subject to the late submissions guidelines.
4
5
1
2
3
4
5
6
7
8
9
10
Percentage
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

Planning, Estimates & Summary

SHORT DESCRIPTION FULL DESCRIPTION
1. Planning, Estimates, Summary
1 Planning
1 Planning Dates missing Planning should include dates you intend to complete specific work products. How do you plan to fit the estimated time into the available days?
2 Estimated Time differs from Plan The time shown in the plan should be the same as the estimated time. There should be no discrepancy. [Why would they be different?! Either the estimate is incorrect, or the plan is incomplete.] All project documentation should be consistent, otherwise major questions and concerns may be raised by customers, management and team members. [What else might be inconsistent/incorrect/etc. ?]
3
4
5
6
7
8
9
10
2 Purpose/Mission/Vision
1 WHY count LOC?? Why would anybody want to count LOC in files and functions?
2 More detail for purpose One important aspect of the Purpose, Mission and Vision is to define (and understand!) the driving force behind the product. (Think of an “info-mercial”: WHY are we making this product? Who will use it? Why do they need it? What is “life” like for them without our product? What will our product do to improve their “lives”? What will “life” be like for them after they have our product?) These details go beyond the technical specifications, and provide a vision (a “star to follow”) in achieving the ultimate goals of satisfying the customer's wants, needs, and expectations.
3 Purpose/Mission/Vision not defined You seem to be missing this section completely.
4
5
6
7
8
9
10
2 Time & Size Estimates
1 Summarize Estimates in report Summarize your estimates in the report for the convenience of “the customer” so as to provide maximal value for your stakeholders. The Excel form provides the supporting details as to how the estimates were derived. Don’t force your stakeholders to search for information that you could have easily provided.
2 Reported estimated time inconsistent The estimated time stated in the project report is different than the Total Time Estimate on the Project Estimates form. All documentation should be consistent!
3 Reported estimated LOC inconsistent The estimated LOC/size stated in the project report is different than the Total Size Estimate on the Project Estimates form. All documentation should be consistent!
4 Over-Estimation Over-estimating time can be a two-edged sword. It can provide a “safety margin” in your timing plan, and it can also bloat your time and resource estimates – making your proposed project timing and cost estimates uncompetitive.
5 Estimate each component The specifications from the customer clearly specify that there be at least the two components: main() and countLOC(). Estimating the time and size of smaller units (as opposed to the overall program) can help to yield more accurate estimates.
6 Estimate in wrong place The Time-Log form is not to be used estimate how long you might take working on the project. To do that, use the Project Estimates tab.
7
8
9
10
Actual Time & Size
1 Actual Time not summarized Summarize the actual values in your report: Actual Time
2 Actual Size not summarized Summarize the actual values in your report: Actual Program Size
3
4
5
6
7
8
9
10
Summary/Retrospective Analysis
1 What will you do in future projects? In the Retrospective Analysis you should try to determine: * What went right? Consider what you would hope to repeat in future projects to help assure successful outcomes. * What could be improved on? Consider what you would hope to avoid or minimize in future projects to help avoid project failure.
2 Process NOT product In the Retrospective Analysis focus on the project outcomes and process improvement, NOT the product.
3
4
5
6
7
8
9
10
General Planning, Estimates & Summary comments:
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10

Requirements & Design

SHORT DESCRIPTION FULL DESCRIPTION
2. Requirements & Design
Requirements and Specification
1 Lack of specification detail Consider the scenario that you are the development team’s representative that met with the customer to clarify the requirements. Ideally somebody else should be able to proceed with the next steps in the development phase given your statement of the requirements along with other supporting material (example: customer provided material such as LOCTest.c.) If someone else implemented the code based on your statement of requirements, would they produce a product that meets the customer’s expectations?
2 LOC not fully defined In subsequent class discussion we refined our definition of a Line of Code (LOC). Your statement of requirements does not include the definition of LOC.
3 Wrong LOC definition Your definition of LOC seems like it might be easily misunderstood or misinterpreted by a developer.
4 countFuncLOC has user interface The customer’s stated specifications contain explicit requirements that are not represented in your statement of requirements: The Function prototype for countFuncLOC shall have no direct user interface (neither input nor output.)
5 countFuncLOC specs not defined The customer’s stated specifications contain explicit requirements that are not represented in your statement of requirements: * The function prototype for countFuncLOC(). The specified function prototype SHOULD be included in your statement of Requirements or High-Level Design. * countFuncLOC shall have no direct user interface. This restriction SHOULD be explicitly stated in your statement of Requirements. Also note that countFuncLOC() is supposed to replace countLOC(). Calling countFuncLOC() should result in accomplishing everything that countLOC() did PLUS the new function LOC counting functionality.
6 Requirements copy/paste Your requirements are stated in essentially the same format as given by the “customer.” How can you (or the customer) confirm whether you have truly understood them, whether they are correct and complete, etc.?
7 Doesn't handle failures Were there any missing requirements not specified by the customer? What if a filename was incorrect, the file was not found, or there was an error opening the file? While this may not have been specified, it is a reasonable expectation that the program will respond “gracefully” (at least not “crash”) due to invalid user input. What should the program do in this case? That is a good (missing!) detail to address with the customer. If you just implement what you believe is the right thing to do, it may not be what the customer is expecting. While this technically would not violate the requirements, as there were none specified, it is best to try to meet the customers’ wants, needs and expectations. When in doubt, ASK.
8 Features out of scope Regarding adding features not specified by the customer, ASK the customer before adding unspecified functionality to avoid providing products that have reduced value, and possibly NO value at all. (Note also that the added effort extended to implement the additionally functionality is essentially given away for free.)
9
10
11
12
13
14
15
Follows specified file naming convention
1 Submitted file named incorrectly The given specifications for naming the submitted file IS a (nonfunctional) requirement. It could be possible that if you name the file incorrectly, it has NO value if the customer/stakeholder receiving the file cannot use it REGARDLESS of the quality of the contents of the file!
2
3
4
5
6
7
8
9
10
Design addresses Requirements
1 Design is missing or incomplete You don't seem to describe HOW you would achieve the requirements. The Design should provide sufficient detail for a developer to follow as a guideline for implementation.
2
3
4
5
6
7
8
9
10
High-Level Design (HLD)
1 HLD missing detail High Level Design should identify the major components and define their interfaces - how they interact with each other.
2
3
4
5
6
7
8
9
10
Detail Design
1 Detailed Design missing Where did you work through the logic details of finding the function name and finding the end of the function? These kinds of complex logic details should be carefully considered in Detail Design BEFORE starting to implement them in code.
2
3
4
5
6
7
8
9
10
General Requirements & Design comments:
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10

Code

SHORT DESCRIPTION FULL DESCRIPTION
3. Code & Executable Program
Complete Code Project Submission
1 Incomplete submission The assignment requires you submit the full solution/project folder (e.g.: Visual Studio project folder) along with the executable (.exe, .jar) file to run your program.
2
3
4
5
6
7
8
9
10
Satisfies Design and Requirements
1 Wrong results Your countFuncLOC() function does not return expected results.
2 Incomplete output As per the given specifications, the program is supposed to report the file name along with the total File LOC, the name of each function and the number of LOC in each function.
3 Wrong method name Your line counter method is improperly named - the specifications require it to be named “countFuncLOC(...)”
4 Wrong method prototype/signature The method countFuncLOC(); does not meet the specified function prototype (name, parameters, return value.)
5 Method/Function name reported incorrectly Entire method/function signature reported; requirements specified the method/function name ONLY to be reported.
6 Method/Function name not reported The name of the method/function was not reported.
7 countFuncLOC spec not followed BOTH the Function LOC and File LOC counting functionality shall be performed by a function called “countFuncLOC”.
8
9
10
Standards, Structure, Organization
1 Need better comments Consider that sometime, someone else (or perhaps you yourself – weeks or months from now) may need to review and/or modify your code. Do them (perhaps your future self!) a huge favor and comment complex logic in your code. You will never have a more clear understanding of the code than you do right now (while you are implementing it.) Comment your logic. If you change your code (modifications, defect resolutions, etc.) be sure to update the comments.
2 Improper data object The specification required that an object/struct be used for reporting the name of the method/function and the LOC count associated with it. Your code did not utilize such an object, but rather just printed the values to the screen.
3 countLOC() should be replaced As per the given specifications, the new function countFuncLOC() should completely replace the original function countLOC(). countFuncLOC() should subsume ALL of the original functionality of countLOC() AND add the new features. main() should just call countFuncLOC().
4 Code duplication There's quite a bit of "is this line a comment or not" code that is duplicated, rather then using existing countLOC logic for detecting valid lines of code
5
6
7
8
9
10
Testing
1 How did you test? How did you determine whether your program functioned as expected?
2 What were the test cases? What specific test cases did your test files consider? What were the expected outcomes?
3 Consider using Test Log Consider summarizing your test plans and results in a Test Log (example provided on Blackboard): * One sheet per component (main, countFuncLOC) or feature (User Interface, LOC Counting, Function Identification) * Define test cases (perhaps BEFORE Design and Code!) such as: Enter Filename - Valid Filename, Enter Filename - Invalid Filename, etc.: + Describe/summarize test case, how test is executed, expected outcomes, observed outcomes, Pass/Fail
4
5
6
7
8
9
10
General Code & Executable comments:
1 Incomplete submission The assignment requires you submit the full solution/project folder (e.g.: Visual Studio project folder) along with the executable (.exe, .jar) file to run your program.
2 Cannot open files Your project files / solution files cannot be opened.
3 No instructions There are no instructions on how to run your program ​and no executable files.
4 Bad instructions Evaluator is unable to run your program based on the provided instructions.
5 JAR file with no instructions Providing the JAR file does NOT tell your client what the command is to actually run the specific class/main method that you’ve created. In other words, the JAR file is just a collection of compiled code, but without looking inside your project. The evaluator has no idea what the name of the class is that should run. In the future, please be sure to provide the full command line for executing your program, or a BAT file that allows the user to run it.
6 Command line doesn’t work Your program did not execute from command line based on the instructions you provided. Consider that your “client” might not have the same development environment as you do. Even if they might have the same IDE, it might be a different version, etc. For Java, there’s many IDEs that are incompatible with each other.
7
8
9
10
1
2
3
4
5
6
7
8
9
10

Time Log

SHORT DESCRIPTION FULL DESCRIPTION
4. Time Log
All Phases Included
1 No Time Log entries NO Time Log entries to-date. The time that you spent on the Estimates and Requirements should be accounted for in the Time Log. (Are you working for free?!) Add Time Log entries for these activities and estimate your actual time spent on them. Be sure to log the time in subsequent project activities.
2 Phases missing The generic phases of the project are identified in the provided in the Development Phase pull-down menu in the Time Log [Project Plan, Req (Requirements), Design (HLD – High-Level Design, DD – Detail Design, Code, Compile, Test (Unit Test, Integration Test, Functional Test), Project Retrospective], as well as the sections of the Software Project Report Template.
3 Phases appear to be fabricated The phases are listed in "perfect" order - as if there was no coding rework after finding bugs, even though bugs are mentioned in other portions of your report
4
5
6
7
8
9
10
Phases in Correct Order
1 Wrong phase ordering The progression of work through the various phases has an expected order: Requirements precedes Design, Design precedes Code, etc.. Time Log entries showing erratic phases “out of order” implies that re-work to resolve defects may be logged under the kind of activity performed rather than in the phase in which the defect was discovered. ALL time spend finding and fixing an error (ALL of the RE-work, regardless of the kind of activity that it is) is logged under the phase in which the defect is discovered. This is the “One Way Street” (the “Marathon Process”) discussed in class. Note that planning to Design, Code, Test an incremental bit of functionality, and then Design, Code, Test another increment is NOT a violation of the “One Way Street.” This is because the incremental/iterative cycles are implementing new work, not doing RE-work. RE-work is logged in the phase that the defect is discovered. NEW work is logged in the phases as they are planned.
2 Incorrect use of "Compile" “Compile” is the act of compiling the source code into the executable (.exe) file – running the compiler. This is also called “building” the program. [Sometimes developers use “build scripts” or “build utilities” to compile/build the code from the command line without opening any IDE (Integrated Development Environment – such as Visual Studio, Eclipse, etc.) It appears that some people are using the term “Compile” to mean “Putting the Report Together.” That is NOT what the “Compile” phase is intended to mean.
3 Should use "Code" instead of Compile With modern computers and compilers, the “Compile” process usually takes a few seconds to a few minutes. [Some very large projects may take hours to compile/build!] Many developers consider compiling to be part of the Coding phase, and that is perfectly fine. If so, the time taken to resolve compile errors would be logged in the Code phase. If you choose to log the compile time separately in a Compile phase, the time taken to resolve compile errors would be logged in the Compile phase (NOT Code phase.) In the Time Log, prolonged time spent in the Compile phase would indicate syntax errors and other errors related to the language that are preventing the compile process from completing successfully.
4 Phase should have been code Bugs found in testing are normally fixed while back in "Code" phase.
5
6
7
8
9
10
Time Logged in each Phase
1 Combined Phases Do not combine phases in Time Log entries (such as Requirements & HLD, Design/Code, Code/Test.) Each activity should be logged as a separate line item in your Time Log. Each entry (line) in the Time Log should capture the time on a specific activity/phase of the project (such as are provide in the pull-down menu for the Development Phase column.)
2 Planning vs. Requirements Note that Planning (including Estimates) and Requirements are two different phases; time should be logged independently for each. In real-world projects, you will be doing some (high-level) planning and estimating BEFORE you actually begin to specify the requirements. So these ARE two different phases of the project. In the Plan phase, when estimating you WILL be evaluating the requirements, the outcome is expected to be “planning” artifacts (estimates, plan, schedule.) THEN when you enter the Requirements phase you will be focusing on producing “requirements” artifacts (requirements statement/specification.)
3 No "Documentation" phase “Documentation” is not a project phase. Documentation should be part of EVERY phase throughout the project.
4 No "Debug" phase “Debug” is not a project phase. Debug is an activity that takes place when a defect is encountered. The time spent to find and fix a defect should be logged in the phase in which the defect was encountered.
5 Time Log appears to be fabricated Time logged for some of the phases appears to not at all reflect the work submitted for that phase/portion of the report.
6
7
8
9
10
General Time Log comments:
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10

Defect Log

SHORT DESCRIPTION FULL DESCRIPTION
5. Defect Log
Identified defect type
1 All defects are NOT change defects ALL of your defects are shown as Change Defects. The Change Defect column is meant to indicate that this defect was introduced in the process of resolving a different defect. MANY “Change Defects” indicates that you are being careless when resolving defects, tending to introduce new defects with each change. Further, it is not possible for your FIRST defect to be a Change Defect (since you cannot have been resolving another defect before the first one.)
2 Logic and Data defects in wrong type For Logic and Data Handling errors identified as being introduced in the Code phase, are these details that were correctly defined in Detail Design and then transcribed into Code incorrectly? Example: * In the Design: X >= Y ? * In the Code: if (X > Y)... This IS a Coding error. Or, were there details missed (or skipped altogether) in Detail Design? The origins of these defects are Detail Design; Missing (or Incorrect). [Unless it is a “Change Defect” that WAS introduced in Code phase.]
3
4
5
6
7
8
9
10
Identified phase injected
1 Didn't identify phase It is important to correctly identify the phases in which the various defects originate so that process improvement efforts can focus on the correct phases of the process.
2 Incorrect Phase identified The project phase that a defect is “injected” (or introduced, created – the phase of origin) can also be considered as the first project phase in which the defect could have been avoided. Examples: If insufficient detail was defined in the Requirements phase resulting in code that does not perform as expected, that is NOT a Design or Code error. It originated in the Requirements phase: Type: Req: Requirements or Specification; Mode: Missing, or Unclear/Misunderstood, Incorrect, etc. If insufficient detail was defined in the Detail Design phase resulting in the developer working out the logic while coding, errors in the logic are NOT Code errors. They originated in the Detail Design (DD) phase: Type: DD: Logic Description, Error Checking, etc. ; Mode: Missing, or Incorrect, etc. For Logic errors identified as being introduced in the Code phase, are these details that were correctly defined in Detail Design and then transcribed into Code incorrectly? Example: In the Design: X >= Y ? In the Code: if (X > Y)... This IS a Coding error. Or, were there details missed (or skipped altogether) in Detail Design? The origins of these defects are Detail Design; Missing (or Incorrect). [Unless it is a “Change Defect” that WAS introduced in Code phase.]
3
4
5
6
7
8
9
10
Identified phase discovered
1 Incorrect Phase identified For Defects indicated as a Logic error discovered in the Code phase - How did you discover the Logic error? If you observed the logic error in the code while you were Coding, then this was indeed discovered in the Code phase (or perhaps a Code Review – CR – phase.) However, if you discovered the logic error while you were running the code, then this is – by definition – discovered in one of the Testing phases. Running the code is Testing the code.
2
3
4
5
6
7
8
9
10
Logged time to find & fix defect
1 Didn't log defect time Time taken to find and fix a defect are recorded in BOTH the Defect Log AND the Time Log. This will allow you to determine what percentage of the overall time for the project was consumed by resolving defects.
2 Defects not fixed You found defects but did not address them.
3
4
5
6
7
8
9
10
Included description of defect
1 Incomplete Defect description The details that you give in the Notes/Description column are to assist you in understanding the cause and/or resolution of the defect in subsequent project analyses.
2
3
4
5
6
7
8
9
10
General Defect Log comments:
1 Give defects unique ID # Give each defect a unique ID # (column A) for ease of referencing them in subsequent analyses.
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10

ALL SD1

Project: SD1 - LOC Counter
Generic Feedback for Project Report Content and Quality:
1. Overall Report & Project
1.1. Various errors (grammar, spelling, capitalization, punctuation, etc.) throughout a work product reduce its overall quality. In the “professional” [and academic] world you will be judged based on your written communication skills. Consider reviewing your written work with someone before submitting it to help you find “obvious” errors. Tutoring in writing can also help you improve your ability to convey your knowledge and ideas. The Academic Achievement Center (AAC) has free tutors to review your writing and help improve your writing skills. http://www.ltu.edu/aac/writingcenter.asp
1.2. In the final report submission REMOVE ALL of the blue text with braces from the Report Template, and where applicable replace the text with your own text. The General Comments area should be completely removed; this is information for you, but should not be included in the report submitted.
1.3. Do NOT paste images of the Logs in the report, as this has very little value. Refer to the external document for the supporting details and summarize the desired results in the report.
1.4. There seems to be an absence of a document describing the functional specifications, planning activities and description of the problem.
2. Timely Submission
2.1. As specified in the Syllabus, assignments are due by the beginning of class on the due date.
2.2. Submitted within 15 minutes of the cutoff time. Risky; Not much margin for error! Did you have any contingency plan?
3. Planning, Estimates, Summary
3.1. Planning
3.1.1. Planning should include dates you intend to complete specific work products. How do you plan to fit the estimated time into the available days?
3.1.2. The time shown in the plan should be the same as the estimated time. There should be no discrepancy. [Why would they be different?! Either the estimate is incorrect, or the plan is incomplete.] All project documentation should be consistent, otherwise major questions and concerns may be raised by customers, management and team members. [What else might be inconsistent/incorrect/etc. ?]
3.2. Time & Size Estimates
3.2.1. Summarize your estimates in the report for the convenience of “the customer” so as to provide maximal value for your stakeholders. The Excel form provides the supporting details as to how the estimates were derived. Don’t force your stakeholders to search for information that you could have easily provided.
3.2.2. Over-estimating time can be a two-edged sword. It can provide a “safety margin” in your timing plan, and it can also bloat your time and resource estimates – making your proposed project timing and cost estimates uncompetitive.
3.2.3. The specifications from the customer clearly specify that there be at least the two components: main() and countLOC(). Estimating the time and size of smaller units (as opposed to the overall program) can help to yield more accurate estimates.
3.2.4. The Time-Log form is not to be used estimate how long you might take working on the project. To do that, use the Project Estimates tab.
3.3. Requirements Statement/Specification
3.3.1. Consider the scenario that you are the development team’s representative that met with the customer to clarify the requirements. Ideally somebody else should be able to proceed with the next steps in the development phase given your statement of the requirements along with other supporting material (example: customer provided material such as LOCTest.c.) If someone else implemented the code based on your statement of requirements, would they produce a product that meets the customer’s expectations?
3.3.2. In subsequent class discussion we refined our definition of a Line of Code (LOC). Your statement of requirements does not include the definition of LOC.
3.3.3. Your definition of LOC seems like it might be easily misunderstood or misinterpreted by a developer.
3.3.4. The customer’s stated specifications contain explicit requirements that are not represented in your statement of requirements:
3.3.4.1. The function prototype for countLOC().
3.3.4.2. countLOC() shall have no direct user interface.
3.3.5. Your requirements are stated in essentially the same format as given by the “customer.” How can you (or the customer) confirm whether you have truly understood them, whether they are correct and complete, etc.?
3.3.6. Were there any missing requirements not specified by the customer? What if a filename was incorrect, the file was not found, or there was an error opening the file? While this may not have been specified, it is a reasonable expectation that the program will respond “gracefully” (at least not “crash”) due to invalid user input.
What should the program do in this case? That is a good (missing!) detail to address with the customer. If you just implement what you believe is the right thing to do, it may not be what the customer is expecting. While this technically would not violate the requirements, as there were none specified, it is best to try to meet the customers’ wants, needs and expectations. When in doubt, ASK.
3.3.7. Regarding adding features not specified by the customer, ASK the customer before adding unspecified functionality to avoid providing products that have reduced value, and possibly NO value at all. (Note also that the added effort extended to implement the additionally functionality is essentially given away for free.)
3.4. Design (High-Level Design, Detail Design)
3.4.1. Identify all diagrams in documents so that they can be referred to in subsequent discussions, analyses, documents, etc.
Example: Figure 1 – Overall System Context Diagram
3.4.2. Where did you work through the logic details of finding the beginning and ending of block comments? These kinds of complex logic details should be carefully considered in Detail Design before starting to implement them in code.
3.5. Testing
3.5.1. How did you determine whether your program functioned as expected?
3.5.2. What specific test cases did your test files consider? What were the expected outcomes? Examples:
Test Case: Expected Outcome:
1. Blank line NOT counted as LOC
2. Line comment (//) beginning at the beginning in column zero (beginning of the line): NOT counted as LOC
3. Line comment beginning after column zero with NO preceding text: NOT counted as LOC
4. Line comment beginning after column zero WITH preceding text: COUNTED as LOC
etc...
How many other test cases are there to consider? Which ones did you test for?
3.5.3. One technique for helping to understand and validate the Requirements (before continuing with development) is to define specific test cases and the expected outcomes in the Requirements phase. The customer can review these and tell you whether you have correctly understood their requirements. You, along with the customer, might discover some misunderstood, missing or incorrect requirements in this process.
3.6. Summary/Retrospective Analysis
3.6.1. In the Retrospective Analysis you should try to determine:
* What went right? Consider what you would hope to repeat in future projects to help assure successful outcomes.
* What could be improved on? Consider what you would hope to avoid or minimize in future projects to help avoid project failure.
3.7. Actual Time & Size
3.7.1. Summarize the actual values in your report:
3.7.1.1. Actual Time
3.7.1.2. Actual Program Size
4. Adherence to Standards
4.1. Follows specified file naming convention
4.1.1. The file submitted does not follow the specified naming convention:
SD1_UserName_n.zip (or .rar) UserName meaning your Banner UserName, n meaning the (single digit) submission number. Example: SD1_bsweet_2.zip
[Why so picky? What if there was a program (“Bot”) that automatically extracted the submitted files based on the specified file naming format? Would the program be “understanding” of file names that do not meet the specified format?
Presumably not! Therefore, files submitted that do not follow the specified naming convention would have NO VALUE.]
4.1.2. The submitted archive file does not have an appropriate file extension (.zip, .rar). This is important for the compressed archive files, as well as any included document that you provide. Without proper extensions, the key stakeholders (the instructors, and in the future your customers, team members, etc.) will need to expend additional effort to open the file. In some cases they may not bother to spend time evaluating your work if they can’t open the file (in which case, it has NO VALUE.)
4.2. Uses specified function calling format
4.2.1. The function submitted does not follow the customer’s specified function prototype/API/signature.
The specified function prototype is:
C: int countLOC (FILE* filePointer);
or
C++: int countLOC (ifstream &file);
or
Java: int countLOC (File file);
If the provided function does not meet the specified format, it will have NO VALUE (even if it performs the specified functionality.)
4.3. Identifies project Purpose/Mission/Vision
4.3.1. Note that the Purpose, Mission and Vision refers to the product, not the project. (It may well be that the purpose of the project is to provide a real-life software development experience, but the Purpose, Mission and Vision in the report/project plan should be referring to the product itself. Why should an investor invest in the product? What is the business case for this project?
4.3.2. One important aspect of the Purpose, Mission and Vision is to define (and understand!) the driving force behind the product. (Think of an “info-mercial”: WHY are we making this product? Who will use it? Why do they need it? What is “life” like for them without our product? What will our product do to improve their “lives”? What will “life” be like for them after they have our product?) These details go beyond the technical specifications, and provide a vision (a “star to follow”) in achieving the ultimate goals of satisfying the customer's wants, needs, and expectations.
4.3.3. Why would anybody care how many lines of code their programs contain? [Note: LOC is just one way to measure program size.]
Note that LOC (and program size in general) by itself says NOTHING about code efficiency, complexity, or quality.
LOC is a measure of program size ONLY.
Program size in general can be used as a normalizing factor in other measurements, such as:
* Productivity (or “velocity”): LOC/hour
* Defect Density: # Defects/LOC
5. Time Log
4.1. General Comments
4.1.1. NO Time Log entries to-date. The time that you spent on the Estimates and Requirements should be accounted for in the Time Log. (Are you working for free?!) Add Time Log entries for these activities and estimate your actual time spent on them. Be sure to log the time in subsequent project activities.
4.1.2. If you have ANY uncertainty about Time/Defect Logging, please refer to the following resources on Blackboard:
Assignments >> Projects >> Project Support Resources
* Time Logs and Defect Logs.pdf
and, Course Utilities >> Project Logs
After reviewing these resources, if you have ANY remaining uncertainty about Time/Defect Logging, please ask.
4.2. All phases included
4.2.1. No time logged for key activities in the project.
The generic phases of the project are identified in the provided in the Development Phase pull-down menu in the Time Log [Project Plan, Req (Requirements), Design (HLD – High-Level Design, DD – Detail Design, Code, Compile, Test (Unit Test, Integration Test, Functional Test), Project Retrospective], as well as the sections of the Software Project Report Template.
4.3. Phases in correct order
4.3.1. The progression of work through the various phases has an expected order: Requirements precedes Design, Design precedes Code, etc.. Time Log entries showing erratic phases “out of order” implies that re-work to resolve defects may be logged under the kind of activity performed rather than in the phase in which the defect was discovered.
ALL time spend finding and fixing an error (ALL of the RE-work, regardless of the kind of activity that it is) is logged under the phase in which the defect is discovered.
This is the “One Way Street” (the “Marathon Process”) discussed in class.
Note that planning to Design, Code, Test an incremental bit of functionality, and then Design, Code, Test another increment is NOT a violation of the “One Way Street.” This is because the incremental/iterative cycles are implementing new work, not doing RE-work. RE-work is logged in the phase that the defect is discovered. NEW work is logged in the phases as they are planned.
Please ASK if you are not sure about this concept.
4.3.2. “Compile” is the act of compiling the source code into the executable (.exe) file – running the compiler.
This is also called “building” the program. [Sometimes developers use “build scripts” or “build utilities” to compile/build the code from the command line without opening any IDE (Integrated Development Environment – such as Visual Studio, Eclipse, etc.)
It appears that some people are using the term “Compile” to mean “Putting the Report Together.” That is NOT what the “Compile” phase is intended to mean.
4.3.3. With modern computers and compilers, the “Compile” process usually takes a few seconds to a few minutes. [Some very large projects may take hours to compile/build!] Many developers consider compiling to be part of the Coding phase, and that is perfectly fine. If so, the time taken to resolve compile errors would be logged in the Code phase.
If you choose to log the compile time separately in a Compile phase, the time taken to resolve compile errors would be logged in the Compile phase (NOT Code phase.) In the Time Log, prolonged time spent in the Compile phase would indicate syntax errors and other errors related to the language that are preventing the compile process from completing successfully.
4.4. Time logged in each phase
4.4.1. Do not combine phases in Time Log entries (such as Requirements & HLD, Design/Code, Code/Test.) Each activity should be logged as a separate line item in your Time Log. Each entry (line) in the Time Log should capture the time on a specific activity/phase of the project (such as are provide in the pull-down menu for the Development Phase column.)
5. Defect Log
5.1. General Comments
5.1.1. Give each Defect Log entry a unique Defect ID # (column A) for ease of referencing them in subsequent analyses.
5.1.2. ALL of your defects are shown as Change Defects. The Change Defect column is meant to indicate that this defect was introduced in the process of resolving a different defect. MANY “Change Defects” indicates that you are being careless when resolving defects, tending to introduce new defects with each change. Further, it is not possible for your FIRST defect to be a Change Defect (since you cannot have been resolving another defect before the first one.)
Be sure that you understand the intent of this column. Please ask if you have any questions.
5.2. Identified defect type
5.2.1. In the provided Defect Type pull-down menu in the Defect Log, each selection is preceded by an indication of the associated phase in which that particular defect Type is associated. If there is any confusion, look under the Menu tab of the Project Log Template for additional clarification. Please ask if you have any questions.
5.3. Identified phase injected/introduced (phase of origin)
5.3.1. It is important to correctly identify the phases in which the various defects originate so that process improvement efforts can focus on the correct phases of the process.
5.3.2. The project phase that a defect is “injected” (or introduced, created – the phase of origin) can also be considered as the first project phase in which the defect could have been avoided. Examples:
If insufficient detail was defined in the Requirements phase resulting in code that does not perform as expected, that is NOT a Design or Code error.
It originated in the Requirements phase: Type: Req: Requirements or Specification;
Mode: Missing, or Unclear/Misunderstood, Incorrect, etc.
If insufficient detail was defined in the Detail Design phase resulting in the developer working out the logic while coding, errors in the logic are NOT Code errors.
They originated in the Detail Design (DD) phase: Type: DD: Logic Description, Error Checking, etc. ;
Mode: Missing, or Incorrect, etc.
For Logic errors identified as being introduced in the Code phase, are these details that were correctly defined in Detail Design and then transcribed into Code incorrectly? Example:
In the Design: X >= Y ?
In the Code: if (X > Y)...
This IS a Coding error.
Or, were there details missed (or skipped altogether) in Detail Design? The origins of these defects are Detail Design; Missing (or Incorrect).
[Unless it is a “Change Defect” that WAS introduced in Code phase.]
5.4. Identified phase removed (or discovered)
5.4.1. For Defects indicated as a Logic error discovered in the Code phase - How did you discover the Logic error? If you observed the logic error in the code while you were Coding, then this was indeed discovered in the Code phase (or perhaps a Code Review – CR – phase.) However, if you discovered the logic error while you were running the code, then this is – by definition – discovered in one of the Testing phases. Running the code is Testing the code.
5.5. Logged time to find & fix defect
5.5.1. Time taken to find and fix a defect are recorded in BOTH the Defect Log AND the Time Log. This will allow you to determine what percentage of the overall time for the project was consumed by resolving defects.
5.6. Included description of defect
5.6.1. The details that you give in the Notes/Description column are to assist you in understanding the cause and/or resolution of the defect in subsequent project analyses. Will the details that you recorded help you to consider how the defect might be avoided or found earlier in future projects?
6. Code & Executable Program
6.1. General Comments
6.1.1. The specification requested you submit the full solution/project folder for Visual Studio, along with the .EXE (or .jar) file to run your program.
6.1.2. Your project files / solution files cannot be opened.
6.1.3. There are no instructions on how to run your program, ,.,..m≤µ≤..,≤≥/l​and no executable files.
6.1.4. Evaluator is unable to run your program based on the provided instructions.
6.1.5. Evaluator is unable to compile and/or run your program.
6.1.6. Providing the JAR file does NOT tell your client what the command is to actually run the specific class/main method that you’ve created. In other words, the JAR file is just a collection of compiled code, but without looking inside your project. The evaluator has no idea what the name of the class is that should run. In the future, please be sure to provide the full command line for executing your program, or a BAT file that allows the user to run it.
6.1.7. Your program did not execute from command line based on the instructions you provided. Consider that your “client” might not have the same development environment as you do. Even if they might have the same IDE, it might be a different version, etc. For Java, there’s many IDEs that are incompatible with each other.
6.2. Satisfies Design & Requirements
6.2.1. Your countLOC() function does not return expected results. The correct result for LOCTest.c is 25.
6.2.2. As per the given specifications, the program is supposed to report the file name along with the LOC.
(The only reason that the file name is visible in the console is because the User typed it there…)
6.2.3. Your line counter method is improperly named - the specifications request it to be named “countLoc(...)”
6.2.4. Your program runs but does not return any results. It appears to be “hung.”
6.2.5. Your program “hangs” or “crashes” when an invalid filename is specified. In the future, consider what the user might do that is not “normal” behavior. If this behavior was not specified by the customer, inform them of the potential issue, ask them how they would like it to be handled, and perhaps recommend some possible alternatives.
6.2.6. There are no given specifications for reporting any other details, such as Total Lines of Text, Total Blank Lines, Total Comment Lines, etc. Is it possible that additional (un-requested) features might cause a problem for the customer? Details regarding missing or unclear requirements and additional features should be address with the customer, not implemented unilaterally.
6.3. Standards, Structure/Architecture, Partitioning
6.3.1. The specifications specifically requested you provide a separate method called “countLOC” rather then perform that logic in your “main”. Consider that your customer/client just wants to use your “countLOC” functionality, and they cannot do so if you embedded all that logic in one “main” method.
6.3.2. Although your code works, the readability is something that can be improved. In the future consider using blank lines (white space) to better separate sections of your code.
6.3.3. There seem to be an extraneous set of code for a JFrame, but it doesn’t actually do anything.
6.4. Useful Comments
6.4.1. Consider that sometime, someone else (or perhaps you yourself – weeks or months from now) may need to review and/or modify your code. Do them (perhaps your future self!) a huge favor and comment complex logic in your code. You will never have a more clear understanding of the code than you do right now (while you are implementing it.) Comment your logic. If you change your code (modifications, defect resolutions, etc.) be sure to update the comments.
Suggestion: Update the comments before you update the code!
6.4.2. Suggestion: All source code files should contain a “header” block comment area for information including:
* File Name.
* Summary of file content.
* Name of author(s).
* Edit date.
* Revision History is highly recommended, summarizing the changes to the file, date of modification, and author of change.
7. Other general comments about “Coding”
7.1. Suggestion: Don’t bury “Magic Numbers” (such as 20) in your code. If you ever need to change the value, you have to remember EVERY place that you used that “Magic Number.” (Did you remember ALL of them? Did you accidentally change a value that was NOT used for the same purpose?) Instead, define configurable parameters as symbolic constants or const:
#define MAX_TABLESIZE (20u) // Note that this occupies NO memory space.
or
unsigned int MAX_TABLESIZE = 20u; // Note that this does occupy memory, but is preferred
// in some coding standards.
That way, if the value ever needs to be changed it can be done in ONE place – and the errors of missing one or more occurrences or inadvertently changing a different value are avoided.
7.2. Suggestion: Here is a convenient way to switch “on” and “off” debug statements (cout/printf) without “commenting them out” or modifying the code:
#define DEBUG // Comment THIS line out or change the symbol (xDEBUG, nDEBUG, etc.)
// to de-activate Debug statements, then re-compile.
// The Symbol DEBUG might also be defined in a build script or the compiler
// command-line options, preprocessor directives, etc.
...
#ifdef DEBUG
debug lines...
#endif

Writing Guidelines

WRITING GUIDELINES:
Project Reports are subject to the “LTU Banned Error List for Writing” (http://www.ltu.edu/arts_sciences/humanities_ss_comm/writing_tools.asp#tab3) and the associated policy:
“A paper with one of the errors listed loses half a letter grade (e.g., from B to B-). Additional errors of the same category (e.g., three sentence fragments) will not lower the grade further, but additional errors in other categories will (one-half letter grade per category).”
Additional reference for further guidance: http://www.ltu.edu/arts_sciences/humanities_ss_comm/writing_tools.asp#tab1
Banned Error List category violations: ___________ * (0.5 Points) = __________
Various errors (grammar, spelling, capitalization, punctuation, etc.) throughout a work product reduce its overall quality. In the “professional” world you will be judged based on your written communication skills. Consider reviewing your written work with someone before submitting it to help you find “obvious” errors. Tutoring in writing can also help you improve your ability to convey your knowledge and ideas. The Academic Achievement Center (AAC) has free tutors to review your writing and help improve your writing skills. http://www.ltu.edu/aac/writingcenter.asp

Revision History

Date: Time: Modified By: Description:
2/14/2015 Gary Givental Original Version. Intent is to provide pulldown selectors for all the sections/sub-sections for automatically adding up the grading. Comments are also available via pull down selectors that show a "short description" for each option. Longer description for each comment is available under each tab (named after the section it represents). Currently, work in progress - the grading all works, now working on the comments
2/17/2015 10:26 PM Gary Givental Fixed grading calculations, cleaned up formatting, added 5th comment column Made up to 10 comments for each category
2/17/2015 11:08 PM Gary Givental Finished all the comment pulldowns
2/17/2015 11:35 PM Gary Givental Added all applicable comments from SD1 Added a general code comment section and general overall comment section
3/1/2015 Ben Sweet * Eliminate "Grading Menus" sheet; place information in Data Validation menu. * Use "absolute" cell referencing rather than "relative" referencing in various calculations. This MAY make copy/paste errors when adding rows less problematic. * Remove Data Validation error in pull-down menu sections to allow free-form comments.
3/4/2015 Ben Sweet * Added absolute cell referencing in Evaluation Form pull-down menus. This helps with copying cell formatting across columns. * Tab and section headings are linked to text on Project Evaluation page. When section or evaluation detail is changed on Project Evaluation page, the change will be automatically reflected on the associated tab.
3/23/2015 Ben Sweet Each line item can be "weighted" by the value in Column A. The difference between the value in Column A on a particular row and the row above is the weighting for that row.
3/24/2015 Ben Sweet, Gary Givental Revise weighting strategy to be based on specific point values in column A (rather than differences.)
6/1/2015 Ben Sweet * Added general comment pull-down menus for sections: Plannin, Estimates Summary ; Requirements & Design ; Time Log ; Defect Log. * Added scored segment of Code & Executable Program segment for complete code project submission.
1/10/2016 Gary Givental Changed percentages to be in smaller increments; Changed the points for each section to be based on % weights; Removed "free points" for timely submission.
1/19/2016 Ben Sweet On main Evaluation page removed large comment about points for on-time & submissions, and added comment to the "Days Late" line.
2/10/2016 Gary Givental Changed the % score to be in 10% increments