Project EvaluationSD2 - countFuncLOC projectProject Team[DATE]Dev.docx

Project EvaluationSD2 - countFuncLOC projectProject
Team:[DATE]Developer 1:ASSIGNMENT
POINTS35WeightEvaluation CriteriaPossibleEarned20%1.
Planning, Estimates, Summary70.0020%2. Requirements &
Design70.0020%3. Code & Executable Program70.0020%4.
Time Log70.0020%5. Defect Log70.00100%350.00Grammar
Penalties0.00<-----0Grammatical ErrorsLate Submission
Penalties0.00<-----0Days Late (-10%/day after due date)FINAL
SCORE350.00EVALUATION DETAILS AND
COMMENTSPlease refer to the comment tabs specific to each
evaluation section for full descriptions of each
commentWeight1. Planning, Estimates, Summary0.000out of
7Comments25% Planning0.000Purpose/Mission/Vision13%Time
Estimate0.00013%Size Estimate0.00012%Actual
Time0.00012%Actual Size0.00025%Summary/Retrospective
Analysis0.000100%General Planning, Estimates & Summary
comments:[General comments here]Weight2. Requirements &
Design0.000out of 7Comments43%Requirements and
Specification0.00014%Follows specified file naming
convention0.00043%Design addresses Requirements0.000High-
Level Design (HLD)Detail Design100%General Requirements &
Design comments:[General comments here]Weight3. Code &
Executable Program0.000out of 7Comments16%Complete Code
Project Submission0.00050%Satisfies Design and
Requirements0.00020%Standards, Structure,
Organization0.00014%Testing0.000100%General Code &
Executable comments:[General comments here]Weight4. Time
Log0.000out of 7Comments34%All Phases
Included0.00033%Phases in Correct Order0.00033%Time
Logged in each Phase0.000100%General Time Log
comments:[General comments here]Weight5. Defect
Log0.000out of 7Comments20%Identified defect
type0.00020%Identified phase injected0.00020%Identified
phase discovered0.00020%Logged time to find & fix

defect0.00020%Included description of
defect0.000100%General Defect Log comments:[General
comments here]
General and TimeSHORT DESCRIPTIONFULL
DESCRIPTIONOverall Report & Project1Great Work!2Well
Done!3Grammar ErrorsVarious 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.asp4Template Artifacts
DetectedIn 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.5Embedded ImagesDo 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.6Report document incompleteThere seems
to be an absence of a document describing the functional
specifications, planning activities and description of the
problem.7Label all diagramsAll 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.8910ERROR:#REF!1Barely on-timeSubmitted
within 15 minutes of the cutoff time. Risky; Not much margin
for error! Did you have any contingency plan?2Late

SubmissionAs specified in the Syllabus, assignments are due by
the beginning of class on the due date.3Very LateSubmissions
later then 24 hours will be subject to the late submissions
guidelines.4512345678910Percentage
100%90%80%70%60%50%40%30%20%10%0%
Planning, Estimates & SummarySHORT DESCRIPTIONFULL
DESCRIPTION1. Planning, Estimates, Summary1
Planning1Planning Dates missingPlanning should include dates
you intend to complete specific work products. How do you
plan to fit the estimated time into the available days?2Estimated
Time differs from PlanThe 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.
?]3456789102Purpose/Mission/Vision1WHY count LOC??Why
would anybody want to count LOC in files and functions?2More
detail for purposeOne 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.3Purpose/Mission/Vision not definedYou seem to
be missing this section completely.456789102Time & Size
Estimates1Summarize Estimates in reportSummarize 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.2Reported
estimated time inconsistentThe estimated time stated in the
project report is different than the Total Time Estimate on the
Project Estimates form. All documentation should be
consistent!3Reported estimated LOC inconsistentThe 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!4Over-EstimationOver-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.5Estimate each componentThe
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.6Estimate in
wrong placeThe 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.78910Actual Time & Size1Actual Time
not summarizedSummarize the actual values in your report:
Actual Time2Actual Size not summarizedSummarize the actual
values in your report: Actual Program
Size345678910Summary/Retrospective Analysis1What 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.2Process NOT productIn the Retrospective Analysis
focus on the project outcomes and process improvement, NOT
the product.345678910General Planning, Estimates & Summary
comments:1234567891012345678910
Requirements & DesignSHORT DESCRIPTIONFULL
DESCRIPTION2. Requirements & DesignRequirements and
Specification1Lack of specification detailConsider 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?2LOC not fully definedIn subsequent class
discussion we refined our definition of a Line of Code (LOC).
Your statement of requirements does not include the definition
of LOC.3Wrong LOC definitionYour definition of LOC seems
like it might be easily misunderstood or misinterpreted by a
developer.4countFuncLOC has user interfaceThe 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.)5countFuncLOC specs not definedThe
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.6Requirements
copy/pasteYour 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.?7Doesn't handle
failuresWere 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.8Features out of
scopeRegarding 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.)9101112131415Follows specified file naming
convention1Submitted file named incorrectlyThe 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!2345678910Design addresses
Requirements1Design is missing or incompleteYou 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.2345678910High-Level
Design (HLD)1HLD missing detailHigh Level Design should
identify the major components and define their interfaces - how
they interact with each other.2345678910Detail
Design1Detailed Design missingWhere 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.2345678910General Requirements & Design
comments:1234567891012345678910
CodeSHORT DESCRIPTIONFULL DESCRIPTION3. Code &
Executable ProgramComplete Code Project
Submission1Incomplete submissionThe 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.2345678910Satisfies Design and
Requirements1Wrong resultsYour countFuncLOC() function
does not return expected results.2Incomplete outputAs 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.3Wrong method
nameYour line counter method is improperly named - the
specifications require it to be named
“countFuncLOC(...)”4Wrong method prototype/signatureThe
method countFuncLOC(); does not meet the specified function
prototype (name, parameters, return value.)5Method/Function
name reported incorrectlyEntire method/function signature
reported; requirements specified the method/function name
ONLY to be reported.6Method/Function name not reportedThe
name of the method/function was not reported.7countFuncLOC
spec not followedBOTH the Function LOC and File LOC
counting functionality shall be performed by a function called
“countFuncLOC”.8910Standards, Structure, Organization1Need
better commentsConsider 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.2Improper data objectThe 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.3countLOC() should be replacedAs 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().4Code duplicationThere'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 code5678910Testing1How did you test?How did you
determine whether your program functioned as expected?2What
were the test cases?What specific test cases did your test files
consider? What were the expected outcomes?3Consider using
Test LogConsider 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/Fail45678910General Code
& Executable comments:1Incomplete submissionThe 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.2Cannot open filesYour project files /
solution files cannot be opened.3No instructionsThere are no
instructions on how to run your program and no executable
files. 4Bad instructionsEvaluator is unable to run your program
based on the provided instructions.5JAR file with no
instructionsProviding 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.6Command line doesn’t workYour
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.7891012345678910
Time LogSHORT DESCRIPTIONFULL DESCRIPTION4. Time
LogAll Phases Included1No Time Log entriesNO 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.2Phases
missingThe 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.3Phases appear to be fabricatedThe 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 report45678910Phases in Correct Order1Wrong phase
orderingThe 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.2Incorrect 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.3Should use "Code"
instead of CompileWith 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.4Phase should have been codeBugs found in testing
are normally fixed while back in "Code" phase.5678910Time
Logged in each Phase1Combined PhasesDo 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.)2Planning vs. RequirementsNote
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.)3No "Documentation"
phase“Documentation” is not a project phase. Documentation
should be part of EVERY phase throughout the project.4No
"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.5Time Log appears to be
fabricatedTime logged for some of the phases appears to not at
all reflect the work submitted for that phase/portion of the
report.678910General Time Log
comments:1234567891012345678910
Defect LogSHORT DESCRIPTIONFULL DESCRIPTION5.
Defect LogIdentified defect type1All defects are NOT change
defectsALL 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.)2Logic and Data defects in

wrong typeFor 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.]345678910Identified phase injected1Didn't identify
phaseIt 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.2Incorrect
Phase identifiedThe 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.]345678910Identified phase discovered1Incorrect Phase
identifiedFor 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.2345678910Logged time to find &
fix defect1Didn't log defect timeTime 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.2Defects not fixedYou found defects but did not address
them.345678910Included description of defect1Incomplete
Defect descriptionThe 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.2345678910General Defect Log comments:1Give
defects unique ID #Give each defect a unique ID # (column A)
for ease of referencing them in subsequent
analyses.234567891012345678910
ALL SD1Project: SD1 - LOC CounterGeneric Feedback for
Project Report Content and Quality:1. Overall Report &
Project1.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.asp1.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
Submission2.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, Summary3.1. Planning3.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
Estimates3.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/Specification3.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
Diagram3.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.
Testing3.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 LOC2. Line comment (//) beginning at the beginning
in column zero (beginning of the line):NOT counted as LOC3.
Line comment beginning after column zero with NO preceding
text: NOT counted as LOC4. Line comment beginning after
column zero WITH preceding text:COUNTED as LOCetc...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 Analysis3.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 & Size3.7.1. Summarize the actual values in your
report:3.7.1.1. Actual Time3.7.1.2. Actual Program Size4.
Adherence to Standards4.1. Follows specified file naming
convention4.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
format4.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);orC++:int countLOC (ifstream &file);orJava: 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/Vision4.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/LOC5. Time
Log4.1. General Comments4.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.pdfand, Course
Utilities >> Project LogsAfter reviewing these resources, if
you have ANY remaining uncertainty about Time/Defect
Logging, please ask.4.2. All phases included4.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
order4.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
phase4.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
Log5.1. General Comments5.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
type5.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 defect5.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 defect5.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 Program6.1. General
Comments6.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≤µ≤..,≤≥/land 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 & Requirements6.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, Partitioning6.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 Comments6.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.orunsigned 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 GuidelinesWRITING 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_t
ools.asp#tab1Banned 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 HistoryDate:Time:Modified
By:Description:2/14/2015Gary GiventalOriginal 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 comments2/17/201510:26 PMGary
GiventalFixed grading calculations, cleaned up formatting,
added 5th comment column
Made up to 10 comments for each category2/17/201511:08
PMGary GiventalFinished all the comment
pulldowns2/17/201511:35 PMGary GiventalAdded all
applicable comments from SD1
Added a general code comment section and general overall
comment section3/1/2015Ben 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/2015Ben 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/2015Ben SweetEach 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/2015Ben
Sweet,
Gary GiventalRevise weighting strategy to be based on specific
point values in column A (rather than differences.)6/1/2015Ben
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/2016Gary
GiventalChanged 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/2016Ben
SweetOn main Evaluation page removed large comment about
points for on-time & submissions, and added comment to the
"Days Late" line.2/10/2016Gary GiventalChanged the % score
to be in 10% increments
CS 111 - Homework 3 p. 1
CS 111 - Homework 3
Deadline
11:59 pm on Friday, February 10, 2017
Purpose
To get more practice using the design recipe to write and test
functions.
How to submit
Each time you would like to submit your work:
• save your current Definitions window contents in a file with
the name 111hw3.rkt

– Note: please use that *exact* name -- do not change the case,
add blanks, etc. If I search for a file with
that name in your submission, I want it to show up! 8-)
• transfer/copy that file to a directory on nrs-labs.humboldt.edu
(preferably in a folder/directory
named 111hw3)
– If you are in a campus lab, you can do so by copying them to
a folder on the U: drive
– If you are not in a campus lab, you can do so by using sftp
(secure file transfer) and connecting to
nrs-labs.humboldt.edu, and then transferring them.
Graphical versions of sftp include WinSCP and Secure Shell
Transfer Client for Windows,
Cyberduck and Fugu for Mac OS X, and FileZilla that has
versions for both Windows and Mac OS X.
(Mac OS X and Linux also come with a command-line sftp -- an
intro to this is included in the
posted handout, "useful details - sftp, ssh, and
~st10/111submit", available on the public
course web site in the References section.)
– Whichever version of sftp you are using, use a host name of
nrs-labs.humboldt.edu if you
are not in a campus lab (you can get away with just nrs-labs for
the host name in a campus lab),
your campus username, and when you are prompted for it, your
campus password. IF you need to give
a port number, give a port number of 22.
• Now that your file is on nrs-labs.humboldt.edu, you need to
log onto nrs-labs.humboldt.edu using ssh, so
you can submit your file to me.

– In BSS 313, the Windows computers have a graphical version
of ssh called PuTTY. There is a
graphical version of ssh for Mac OS X named Jelly FiSSH,
(although Mac OS X and Linux also come
with command-line ssh, and an intro to this is also included in
the "useful details - sftp, ssh, and
~st10/111submit" handout.)
– Again, whichever version of ssh you are using, use a host
name of nrs-labs.humboldt.edu if
you are not in a campus lab (you can get away with just nrs-labs
for the host name in a campus
lab), your campus username, and when you are prompted for it,
your campus password. IF you need to
give a port number, give a port number of 22.
• WHILE you are logged onto nrs-labs:
– IF you saved your file in a folder, use cd to change to the
folder/directory where you saved it -- for
example, if you saved it in the folder 111hw3, then you would
go to that directory by saying:
cd 111hw3
– use the ls command to make sure your 111hw3.rkt file is
really there:
ls
– type the command:

~st10/111submit
...and when asked, enter a homework number of 3
...and when asked, enter y, you do want to submit all files with
an appropriate suffix (I don't mind
getting some extra files, as long as I also get 111hw3.rkt; I'd
rather receive too many files than too
few due to typos.)
...make sure to carefully check the list of files submitted, and
make SURE it lists 111hw3.rkt as
having been submitted! (The most common error is to try to run
~st10/111submit while in a
different directory than where your files are...)
Important notes
• NOTE: it is usually fine and often encouraged if you would
like to write one or more helper functions to
help you write a homework problem's required functions.
– HOWEVER -- whenever you do so, EACH function you define
IS EXPECTED TO follow ALL of the
design recipe steps: after thinking about the function and the
kind of data involved, write its signature,
then its purpose statement, then its function header, then its
tests/check- expressions, then replace its
... body with an appropriate expression
• Remember: Signatures and purpose statements are ONLY
required for function definitions -- you do NOT
write them for named constants or for non-function-definition
compound expressions.
• Remember: A signature in Racket is written in a comment, and

it includes the name of the function, the
types of expressions it expects, and the type of expression it
returns. This should be written as discussed in
class (and you can find examples in the posted in-class
examples). For example,
; signature: purple-star: number -> image
• Remember: a purpose statement in Racket is written in a
comment, and it describes what the function
expects and describes what the function returns (and if the
function has side-effects, it also describes
those side-effects). For example,
; purpose: expects a size in pixels, the distance between
; points of a 5-pointed-star, and returns an image
; of a solid purple star of that size
• Remember: it is a COURSE STYLE STANDARD that named
constants are to be descriptive and written
in all-uppercase -- for example,
(define WIDTH 300)
• You should use blank lines to separate your answers for the
different parts of the homework problems. If
you would like to add comments noting which part each answer
is for, that is fine, too!
• Because the design recipe is so important, you will receive
significant credit for the signature, purpose,
header, and examples/check-expects portions of your functions.
Typically you'll get at least half-credit for
a correct signature, purpose, header, and examples/check-
expects, even if your function body is not correct
(and, you'll typically lose at least half-credit if you omit these
or do them poorly, even if your function
body is correct).

Problem 1
Start up DrRacket, (if necessary) setting the language to How
To Design Programs - Beginning Student
level, and adding the HTDP/2e versions of the image and
universe teachpacks by putting these lines at the
beginning of your Definitions window:
(require 2htdp/image)
(require 2htdp/universe)
Put a blank line, and then type in:
• a comment-line containing your name,
• followed by a comment-line containing CS 111 - HW 3,
• followed by a comment-line giving the date you last modified
this homework,
• followed by a comment-line with no other text in it --- for
example:
; type in YOUR name
; CS 111 - HW 3
; last modified: 2017-02-04
;
Below this, after a blank line, now type the comment lines:
;
; Problem 1
;
Note: you are NOT writing a function in this problem -- you are

just writing two compound expressions.
Sometimes, when a function returns a number with a fractional
part, especially a number such as the result of
(/ 1 3), it becomes difficult to give an expected value in a
check-expect that is "exact enough" for a
passing test. Yet, if the expected value is "close enough" to the
actual value, we might like to be able to
decide that that is good enough for our purposes.
That is why, along with several additional check- functions,
BSL Racket also includes check-within,
which expects THREE arguments:
• the expression being tested, which in check-within's case
should be of type number
• an approximate expected value for that expression
• a number that is the largest that the difference between the
expression and the expected value can be and
still consider this to be a passing test. (In math, this maximum
difference is also called a delta.)
As a quick example, what if you simply wanted to test whether
BSL Racket's predefined pi was within .001
of 3.14159? This check-within expression can do this, and show
that it is:
; passing test
(check-within pi ; expression being tested
3.14159 ; APPROXIMATE expected value
.001) ; how close these must be to be "close
enough"
But if you want to know if its predefined pi is within .000001 of
3.14159, this check-within

expression can do this, and show that it is not:
; failing test
(check-within pi
3.14159
.000001)
Just to PRACTICE writing a few expressions using check-
within:
• write a check-within expression that will result in a passing
test for testing what the expression
(/ 1 7)
...should be approximately equal to;
• write a check-within expression that will result in a passing
test for testing what the expression
(* pi 100)
...should be approximately equal to.
Problem 2
Next, in your definitions window, after a blank line, type the
comment lines:
;
; Problem 2
;
True story: my spouse likes to set every item that displays a

temperature to display that temperature in
Celsius. That prompts an idea: design a function that expects a
temperature given in Celsius, and returns the
equivalent Fahreheit temperature. Write such a function cels-
>fahr, using the following design recipe
steps:
(It is reasonable to search the web or an appropriate reference
for the conversion formula for this -- consider
it problem research.)
2 part a
Write an appropriate signature comment for this function.
2 part b
Write an appropriate purpose statement comment for this
function.
2 part c
Write an appropriate function header for this function (putting
... ) for its body for now).
2 part d
Write at least 2 specific tests/check-expect or check-within
expressions for this function.
2 part e
Only NOW should you replace the ... in the function's body with
an appropriate expression to complete
this function. Run and test your function until you are satisfied
that it passes its tests and works correctly.
Finally, include at least 2 example calls of your function (such
that you will see their results) after your
function definition.

Problem 3
Next, in your definitions window, after a blank line, type the
comment lines:
;
; Problem 3
;
I decide I'd like a function name-badge that expects a name and
a color, and returns an image of a "name
badge" for that name with letters of that color: a shape (of your
choice of shape, style, and background color)
with the given name (of your choice of font size, but using
letters of the given color) in its middle. Somehow
make the width of your "badge" be based on the name's length.
(HINT: remember that string-length expects a string and returns
how many characters are in that
string.)
3 part a
3 part b
function.
3 part c

3 part d
Write at least 2 specific tests/check-expect expressions for this
function.
3 part e
this function.
Run and test your function until you are satisfied that it passes
its tests and works correctly.
Problem 4
FUN FACT: BSL Racket includes a make-color function.
make-color expects three arguments, each an integer number in
[0, 255], representing its red, green, and
blue values, respectively, and returns a color made up of those
red, green, and blue values. Optionally, it can
take a 4th argument, another integer in [0, 255], giving the
transparency of that color (0 is completely
transparent, 255 has no transparency).
But - to play with this is a little inconvenient, because to "see"
what the returned color looks like, you have to
use the resulting color in some image function.
Design a function color-box that expects desired red, green, and
blue values, and returns a solid square
image whose color has those red, green, and blue values. (You
can pick a reasonable constant size for this

square.)
OPTIONAL: if you'd like, you can design this to also expect a
transparency value (that is, you can design it
to expect 4 arguments instead of 3 arguments).
4 part a
4 part b
function.
4 part c
4 part d
Write at least 2 specific tests/check-expect or check-within
expressions for this function.
4 part e
this function.

Problem 5
Next, in your definitions window, type the comment lines:
;
; Problem 5
;
5 part a
Remember that place-image expects a scene expression for its
4th argument. It can be convenient to use
a named constant for this scene, especially if you will be using
it in a number of place-image expressions
and if it might itself include several unchanging elements.
You are going to be creating some scenes in later parts of this
problem, so for this part, define the following
named constants:
• define a named constant WIDTH, a scene width of your choice
(except it should not be bigger than 1300
pixels).
• define a named constant HEIGHT, a scene height of your
choice (except it should not be bigger than 400
pixels).
• define a named constant BACKDROP, an unchanging,
constant scene that will serve as a backdrop scene in
some future problems.
– its size should be WIDTH by HEIGHT pixels

– it should include at least one visible unchanging image of
your choice (and you may certainly include
additional visible unchanging images if you wish).
• (you may certainly include additional named constants, also, if
you wish!)
5 part b
Consider a "world" of type number -- starting from a given
initial number, in which that number changes as a
ticker ticks, and in which the number determines what is shown
where (or how) in a scene.
For this world, big-bang's to-draw clause will need a scene-
drawing function that expects a number,
and produces a scene based on that number. Don't get too far
ahead of yourself, here! Just decide what
image(s) is/are going to be ADDED to your BACKDROP scene
from 5 part a based on a number value.
Do something that is at least slightly different than the posted
class examples, and at least slightly different
than what you did for the Week 3 Lab Exercise.
(For example, an image could be placed in the BACKDROP
whose size depends on that number -- and/or an
image's x-coordinate within the BACKDROP could be
determined by that number -- and/or an image's y-
coordinate within the BACKDROP could be determined by that
number -- and/or part an image's color or
transparency could be determined by that number -- and/or some
combination, letting it determine both the
x- and y-coordinate, or both its color and and its size, for
example.)

5 part c
function.
5 part d
5 part e
Write at least two specific examples/tests/check-expect
expressions for this function, placed either
before or after your not-yet-completed function definition,
whichever you prefer.
5 part f
Finally, replace the ... in this function's body with an
appropriate expression to complete it. For full credit,
make sure that you use your BACKDROP scene from 5 part a
appropriately within this expression.
Also include at least 2 example calls of your function (such that
you will see their results) after your function
definition.
5 part g
What change do you want to happen to your world number as
the world ticker ticks? Will it increase by 1?
decrease by 1? Increase and/or decrease by varying amounts?
Decide how your world number will change on each ticker tick.
If your change can be done by a built-in
function such as add1 or sub1, that is fine. Otherwise, using the
design recipe, develop this function, that

expects a number and produces a number.
• (if you develop your own function here, REMEMBER to do all
the steps you have been doing for the other
functions in this homework -- first write its signature, then its
purpose statement, then its function header,
then its tests/check-expect expressions, then replace its ... body
with an appropriate expression)
Then write a big-bang expression consisting of an initial
number, and a to-draw clause with the name of
your scene-drawing function from 5 parts b-f, and an on-tick
clause with the name of your (new or
existing) number-changing function -- something like:
(big-bang initial-number-you-choose
(to-draw name-of-your-scene-drawing-function)
(on-tick name-of-your-number-changing-function))
(By the way, you can also change the speed of the ticker in this
on-tick clause if you would like to -- give
it an optional 2nd expression, a number that is a ticker-rate-
expression, and the ticker will tick
every ticker-rate-expression seconds.)
Now you should see something changing in your scene, and now
you are done with this problem.

MCS 5103 - Software Engineering January 30, 2017
Software_Development_Assignment_2_201701.Docx
Page 1 of 5
Assignment:
Enhancement to Software Development Assignment #1.
ORIGINAL REQUIREMENTS:
Develop a software application that will do the following:
prompt, or menu.
ple files are specified or a
directory is specified (not required, but a nice optional feature),
the program operates on each file in sequence.
into a linked-list with one line in each “node” of the
list.
in the file.

ADDITIONAL NEW/CHANGED REQUIREMENTS – Add the
following functionality to a new function –
countFuncLOC();:
You MUST use one of “starter” program files provided (.c, .cpp
or .java) as your basis for SD2. You will be making your
modifications for the SD2 project to another developer’s SD1
implementation. You should change the original code as little
as possible to avoid the risk of making too many changes to
“working” code.
Count the Function LOC:
file.
each function in the file:
The main program performs the following operations:

on LOC counting function
name and the corresponding function LOC
BOTH the Function LOC and File LOC counting functionality
shall be performed by a function called “countFuncLOC”.
countFuncLOC receives a pointer to a valid open file and a
pointer to a table for function data as passed parameters, and
returns the integer number of LOC in the file.
You must use the following “countFuncLOC” function
prototype/definition:
int countFuncLOC (FILE *filePointer, FUNCDATA
*funcDataPtr); /* C-language function prototype */
int countFuncLOC (ifstream &file, FUNCDATA *funcDataPtr);
// C++ function prototype
int countFuncLOC (File file, List functionDataList)
// Java method definition
int countFuncLOC (String fileName, List functionDataList)
// Alternative Java method definition

countFuncLOC will “absorb” the countLOC functionality.
The Function LOC data shall be stored in a table defined in the
main program and accessed by countFuncLOC() through a
pointer to the table.
All user input/output interaction functionality shall be
performed by the main program; countFuncLOC shall have no
direct
user interface.
The program shall be written in C, C++ or Java.
Page 2 of 5
SUGGESTED DATA STRUCTURES
C / C++

An appropriate “typedef” should be used to define a data type
for the Function LOC data, such as:
typedef struct
{
int funcLOC;
char funcName[MAX_NAME_SIZE]; /* See note below…
*/
} FUNCDATA;
* Note regarding funcName[] array: it is acceptable to define a
constant array size with a “reasonable” MAX
size for the function name (20 to 30 characters for a function
name SHOULD be sufficient…)
IF YOU PREFER, you may use a pointer to a string in the
FUNCDATA structure and use dynamic memory
allocation as needed rather than a fixed function name length.
The table for the Function LOC data can be a fixed array as
follows:
FUNCDATA funcDataTable[MAX_FUNCTIONS]; /* See note
below… */
* Note regarding funcDataTable[] array: it is acceptable to

define a constant array size with a “reasonable”
MAX size for the number of functions in a file (10 to 20
functions in a file SHOULD be sufficient…)
IF YOU PREFER, you may use dynamic memory allocation as
needed rather than a fixed data table size.
JAVA
As Java is an object oriented language, here’s one example of a
data structure you might consider using to store the
“function” (method ) information:
public class FunctionData
{
String functionName = null;
int functionLOC = 0;
}
Using this object to store an individual function’s LOC, you can
then use a List to store FunctionData objects as your
program encounters new functions to count the LOC for. Here’s
an example:

public List<FunctionData> functionDataList = new
ArrayList<FunctionDataList>();
Alternatively, you may consider using an Array “primitive” to
store FunctionData object, or even a HashMap. Be sure to
change your “int countFuncLoc(File file, List funcDataList)”
function call accordingly if you choose to use something other
than a List.
Page 3 of 5
Additional Information:
A “Line of Code”, LOC, is defined for our exercise as a non-
blank, non-comment line. A line containing any printable (i.e.:
non-“white space” character such as space, tab, etc.) that is
NOT in a comment is counted as LOC.
A comment in C/C++-language begins with either “//” or “/*”.

A line comment beginning with “//” ends at the end of the
line. A block comment beginning with “/*” ends with “*/”.
* A block comment may begin on a line that is also counted as
LOC.
* A block comment may span more than one line.
A function in C-language has the basic form:
optional_additional_modifiers function_return_type
function_name (type argument, additional arguments )
{
function body
}
example:
signed int loc_counter ( file * fileptr)
{
body …
}
The first line (‘signed int loc_counter (…)’ in the example
above) and opening brace (if it is on a line by itself, as in the

example above) in the function definition DO COUNT as
Function LOC.
Note that the program must not mistake a function prototype as
the beginning of the function itself:
function_return_type optional_additional_modifiers
function_name (type argument, additional arguments );
The program is not a compiler and does not need to recognize
valid lines of code in a particular programming language.
Page 4 of 5
Process Requirements:
BEFORE YOU BEGIN:
minutes, not “calendar” time) that it will take you to
complete the project (time measured from the time you begin

this estimation until you have a complete, properly
functioning program.)
completed program.
Template to facilitate these estimates.
AS YOU WORK:
time) that you spend working on the project INCLUDING:
is: Any POST project analysis,
wrap-up, documentation, etc.
INCLUDING (but not limited to):

Logic errors
WHEN YOU’RE DONE:
Analysis”):
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:
ools.asp#tab1
ools.asp#tab3
ools.asp#tab1
Page 5 of 5
Deliverables: - Students are expected to submit their own
original work
You MUST use the project templates provided to you on
Blackboard under
Resources”
Project Report – use “TEMPLATE – Software Project Report”
f TOTAL time to develop the program

(INCLUDING planning, preparation, documentation,
debug and test, and retrospective analysis time.)
– come up with a schedule of when you will
complete the various phases of this assignment
software development process steps performed (requirements,
design, test cases & results, etc.)
file “SD2_ProjectReport_[username]”
The Report should contain references to all additional
supporting documents. ALL documents submitted should
contain
author identification and should indicate to what assignment
they pertain.
Project Estimation, Time Logs, Defect Logs – use “TEMPLATE
– Project estimation, Time Log, Defect Log”
ectLogs_[username]”

Testing – use “TEMPLATE – Test Use Case Scenarios and
Logs”
2_TestingLogs_[username]”
Software:
include the ENTIRE project folder containing all project
files – such as .vcxproj. Note that the project files usually
contain the source code and executable in the various
subdirectories.)
[User Story: As a project reviewer, I want to be able to
recompile/re-build the submitted project, so that I can
overcome run-time errors and other problems associated with
incompatible versions of the development tools between

the developer’s development tools and my own, thereby
allowing me to run the submitted project on my own
computer.]
Assignment Submission:
submitted in the appropriate
“Assignments” area on Blackboard by the BEGINNING
of class on the due date.
or .HTML files.
WinZip or RAR format.
meaning your Banner UserName - example: SD2_bsweet]
Assignment Date: January 31, 2017 @ 5:45pm
Due Date: February 9, 2017 @ 5:45pm – 1.2 weeks

Project EvaluationSD2 - countFuncLOC projectProject Team[DATE]Dev.docx

Recommended

Recommended

More Related Content

Similar to Project EvaluationSD2 - countFuncLOC projectProject Team[DATE]Dev.docx

Similar to Project EvaluationSD2 - countFuncLOC projectProject Team[DATE]Dev.docx (20)

More from briancrawford30935

More from briancrawford30935 (20)

Recently uploaded

Recently uploaded (20)

Project EvaluationSD2 - countFuncLOC projectProject Team[DATE]Dev.docx