Effective Software Engineering
Pedagogy
By
Evelyn Stiller and Cathie LeBlanc
Plymouth State College
Can We be Content with SE
Education?
 Large-scale software development efforts show no
evidence of change from the 70’s and 80’s.
 FLORIDA welfare system.
 IRS project failures cost tax payers $50 billion
annually.
 FAA air traffic control system ...
Current State of the Air Traffic
Control System
Resulted in the squandering of $2.5 billion!
Why Are We Failing to Produce
Strong Advocates of SE?
 SE = terms and concepts.
 SE is difficult.
 We can teach the general mechanics of modeling
software.
 We have to anticipate students’ struggle and
dissatisfaction with SE and be proactive.
Recommendation for Teaching
SE Effectively
 Make SE real
 Make SE fun
 Make SE critical
 Make SE accessible
 Make SE successful
 Reflect on the process of SE
Make SE Real
 Students have 1 to 2 week assignments pre SE.
 Expose students to a larger-scale development
efforts BEFORE their software engineering course.
 E.g. a simple programming language interpreter.
 These students enter our SE course eager to learn.
Sample Assignment Sequence
1)
2)
3)
4)
5)
Token extraction.
Lexical analysis - identifying basic language elements, literal values and operators.
Lexical analysis - identifying keywords and identifiers, start building the symbol table.
Syntactic analysis - enforce proper syntax for a subset of language statements.
Syntactic analysis - enforce proper syntax for the remaining statement in our simple
language.
6) Building aggregate structures - build internal representations for block-oriented
statements such as loops, conditions, and function definitions. Also add function calls
to possible statements.
7) Semantic analysis - enforcing variable declaration, adding identifier scope to the
symbol table, and matching actual and formal parameters in function calls.
8) Execution - implement the execution a subset of the commands in our simple language.
9) Execution - implement the execution of loops and conditional statements.
10) Executions - implement the execution of function calls and return values.
Make SE Fun
 Consider student motivation.
 SE is hard work, so motivation is critical.
 What motivates students?
 Multimedia elements are also make an application
exciting.
Make SE Critical
SE project size is crucial.
The project must be somewhat complex.
The project must be large enough to require
a team of 4-6 students to complete.
Sample SE Projects
On-line Clue or variation thereof.
A MUD variation.
Other role-playing games – Soap Opera
Sample failure: VPCT
Make SE Accessible
 Provide students with a clear set of steps.
 Each step should result in a deliverable.
 When possible reduce or delay the required
abstract thinking.
 The modeling notation should not be
prohibitively complex.
Project Deliverables
Requirements Analysis
Refined
Requirements
Specification
Use Case
Diagrams
Informal
Scenarios
Class
Diagrams
Use
Cases
Scenarios
Product Design
Process
Architecture
Persistence
Solution
User interface
Mockups
Class Design
Class
Skeletons
Object
Diagrams
Interaction
Diagrams
Implementation
Implementation
Plan*
Class
Definitions
System Test
Report *
Integration
Test Report*
Testing
Test
Plan*
Unit Test
Report*
* Indicates a partial deliverable is required
Make SE Successful
 Even if students are unable to deliver 100%
functionality, they should succeed anyway.
 Have students incrementally implement their
projects, prioritizing core functionality.
 Engage in “shoring up” the project in the last 3
weeks of the course.
Shoring-up the Project
 Determine risk.
 Rank the incomplete elements in terms of their
importance to the project.
 Of the most important elements, determine if any
are too risky to implement.
Assessing Risk
 Unfamiliarity with algorithms or technology.
 Abstractness of current design.
 Quantity left to code.
 Complexity.
 Possibility of error in current design.
 Poorly structured solution.
Assessing Importance
 Place remaining modules to implement in context
of interaction diagrams.
 Determine what functionality is at stake, if
remaining risky modules are not implemented.
 Determine how many students depend on this
functionality for their portions of the project.
 Create an ordered list of elements based on level
of risk and criticality of functionality.
Reflect on the Process of
Software Engineering
 Students invariably fail to appreciate the true complexity
of the functional requirements, which models reality.
 Despite giving feedback that additional or more complex
scenarios are required, students usually add only a few
new scenarios.
 During implementation they feel the crunch.
 Thus, it is vital to reflect on the process of SE by asking a
series of questions which illuminate what might have
been done differently.
Sample Set of Questions
 Did lack of appreciation of the true
complexity of certain aspects of the
functionality of the system cause
problems for you?
 Were new areas of functionality needed
after analysis or design had been
completed?
 Were
additional
human-computer
interfaces required after product design
was complete?
 Was the flow of control between
human-computer interfaces problematic
or awkward?
 Was
object
persistence
more
problematic than anticipated?
 Was
inter-process
communication
insufficient to support the full
functionality of the system?
 Was the process architecture inefficient?
 Did your system require a significant
number of methods and/or classes beyond
what was provided for during design?
 Were methods more complex than the
algorithms specified during design?
 Did classes require a significant number
of additional attributes from the original
design?
 Did originally designated container
classes need to be modified during
implementation?
 Did elements of the system require
restructuring after the design phase?
 Did unit testing take additional time
because the design had to be altered?
 Did
integration
testing
require
additional time because the inter-class
interfaces
were
inconsistent
or
inadequate?
 Did
integration
testing
require
additional time because unit testing was
not sufficiently thorough?
 Did system testing reveal errors not
caught during integration or unit
testing?
Conclusion
 Our goal should be to create SE ambassadors to industry.
 We must make SE relevant, exciting, and important to our
students by engaging them in exciting team-oriented
development projects.
 We should make the process deliverable oriented, but not
bury them in deliverables.
 We cannot expect perfection from our students the first
time they engineer a complex application, so reflecting on
the process of SE is vital.