|
This is under development... so students should check back often.
The course will have two parallel activites:
- traditional
lectures, HW, and quizzes and
- the project.
Note that you will most likely
need to study the material required for your
group before I present it in class.
The project for this course will be the development of a software
system for a mobile robot. Mobile robots are beneficial in many
applications especially for interplanetary exploration and operation
in extreme environments. A radio-controlled truck with an on-board
computer will be controlled by a desktop computer via wireless LAN
through the internet [Ref. 1]. Therefore, the truck will be able to
operate remotely anywhere in the world with a wireless internet
connection coverage. In addition, the truck will have an onboard
camera to display the real-time environment.
|
We will provide the hardware (we only have one of these, and cannot
handout to each team!):
Each team will be given a servo control board and two servos
for preliminary tests.
|
|
|
|
|
At the end of the semester,
the truck will be tested in a remote environment and you will attempt to find
several objects in the field (e.g. 3 fake landmines) as fast as possible.
If you run over a landmine, your test will be over.
The students will control the robot from the Penn State campus.
Dr. Long will take the robot to Penn State's Foundry Park
for the test. (we will ask if we can use the
Mars Yard at JPL
or the
Army's Aberdeen Proving Grounds but we cannot count on this).
|
LNL at JPL's Mars Yard in 2008
|
The project evaluation
will focus on the quality of the software as well as the documentation,
team communications, and final test. This is not a programming project,
it is a software engineering system project.
This course project is designed to:
- Provide hands-on experience in software engineering through the
development of a relatively small software system for a mobile robot;
- Simulate the real working environment in a large software company
by having the students in the class work together as a team. Each student
will work in a small group functioning as a part of a software development
model. The instructor will be a customer who indicates the system needs;
- Emphasize the communication and collaboration skills among small
groups in the software development model which are the most crucial skills
in developing a large and complex software systems.
There will be two completely separate teams (blue and white), competing
against each other. Students on each of these teams will be separated
into six small groups according to the V-Life cycle software
engineering model based on their interest:
- Requirements
- Design
- Coding
- Testing
- Validation
- Verification
As shown in the figure below (but keep in mind this figure could be drawn in
many different ways and there could be many more interconnections shown).
From this figure each group can see the other groups
that it must interact with, for example the Design
Group must interact with the Requirements, Testing,
and Coding Groups..
Each of these sub-groups will have roughly four-five people each.
After the customer needs have been discussed, each group will work
together to produce the software system, design, and documentation
according to the software engineering approaches [Ref. 2, 3]. The
communication log between each group must be recorded via Penn
State Wiki (https://wikispaces.psu.edu). Every week, each group
must give a brief oral presentation about their progress in the
class. At the end of the software development cycle, the final
product will be demonstrated and the report must be submitted.
Each group must follow the life-cycle model, and cannot
start their main task until the group before it
gives them their document. (e.g. Coding cannot start until
the Design Group gives them the Design).
Each group needs to read the appropriate sections of
Refs 2 - 4, but I have tried to briefly summarize the roles
below (mainly taken from SWEBOK).
ROLES OF EACH GROUP:
- REQUIREMENTS (Chap. 6 - 10
of textbook,
Ref. 3 , and
Ref. 4
):
The Software Requirements Area is
concerned with the elicitation, analysis, and specification
of software requirements. It is widely
acknowledged within the software industry that software
engineering projects are critically vulnerable when these
activities are performed poorly.
Software requirements express the needs and constraints
placed on a software product that contribute to the
solution of some real-world problem.
An essential property of all software requirements is that
they be verifiable. It may be difficult or costly to verify
certain software requirements.
Functional requirements describe the functions that the
software is to execute; for example, formatting some text
or modulating a signal. They are sometimes known as
capabilities.
Nonfunctional requirements are the ones that act to
constrain the solution. Nonfunctional requirements are
sometimes known as constraints or quality requirements.
Some requirements represent emergent properties of
software that is, requirements which cannot be
addressed by a single component, but which depend for
their satisfaction on how all the software components
interoperate.
Software requirements should be stated as clearly and as
unambiguously as possible, and, where appropriate,
quantitatively. It is important to avoid vague and
unverifiable requirements.
Requirements elicitation is concerned with where
software requirements come from and how the software
engineer can collect them. It is the first stage in building
an understanding of the problem the software is required
to solve.
- DESIGN (Chap. 11 - 16 of textbook,
Ref. 3 , and
Ref. 4
):
Design is defined as both the "process
of defining the architecture, components, interfaces, and
other characteristics of a system or component" and "the
result of that process". Viewed as a process, software
design is the software engineering life cycle activity in
which software requirements are analyzed in order to
produce a description of the softwares internal structure
that will serve as the basis for its construction. More
precisely, a software design (the result) must describe the
software architecture that is, how software is decomposed
and organized into components and the interfaces
between those components. It must also describe the
components at a level of detail that enable their construction.
There are two parts to design:
- Architectural design:
Architectural design describes how software is
decomposed and organized into components (the
software architecture)
- Detailed design:
Detailed design describes the specific behavior of
these components.
The output of this process is a set of models and artifacts
that record the major decisions that have been taken.
Many notations and languages exist to represent software
design artifacts. Some are used mainly to describe a
designs structural organization, others to represent
software behavior. These can be static or dynamic
descriptions. Examples of static dscriptions include:
class diagrams, component diagrams, structure charts,
entity-relationship diagrams, and others. Examples of
dynamic descriptions include: activity diagrams,
data flow diagrams, flowcharts, sequence diagrams,
pseudocode, and others.
- CODING (Chap. 17 - 21 of textbook,
Ref. 3 , and
Ref. 4
):
The term software coding (or construction) refers to the detailed
creation of working, meaningful software. Some of the key
desirable traits are:
- Minimal complexity
- Anticipate change
- Construct for testing and verification
- Use standards
The first three concepts apply to design as well as to
construction.
Coding cannot start until the Design Group finishes
their Design document. And the coding should be fairly
straight-forward, once the design is completed.
- TESTING (Chap. 23 of textbook,
Ref. 3 , and
Ref. 4
):
Testing is an activity performed for evaluating software
quality, and for improving it, by identifying defects and
problems.
Software testing consists of the dynamic verification of the
behavior of a program on a finite set of test cases, suitably
selected from the usually infinite executions domain,
against the expected behavior.
It is currently considered that the right attitude towards
quality is one of prevention: it is obviously much better to
avoid problems than to correct them. Testing must be seen,
then, primarily as a means for checking not only whether
the prevention has been effective, but also for identifying
faults in those cases where, for some reason, it has not been
effective.
Testing theory warns against ascribing an unjustified level
of confidence to a series of passed tests. Unfortunately,
most established results of testing theory are negative ones,
in that they state what testing can never achieve as opposed
to what it actually achieved. The most famous quotation in
this regard is the Dijkstra aphorism that “program testing
can be used to show the presence of bugs, but never to
show their absence.” The obvious reason is that complete
testing is not feasible in real software. Because of this,
testing must be driven based on risk and can be seen as a
risk management strategy.
Unit testing verifies the functioning in isolation of software
pieces which are separately testable. Depending on the
context, these could be the individual subprograms or a
larger component made of tightly related units.
Integration testing is the process of verifying the interaction
between software components.
System testing is concerned with the behavior of a whole
system.
- VERIFICATION (Chap. 22 of textbook,
Ref. 3 , and
Ref. 4
):
Verification is an attempt to
ensure that the product is built correctly, in the sense that
the output products of an activity meet the specifications
imposed on them in previous activities, i.e. "are we building
the product right?" Are we meeting the Requirements?
"Software Verification and Validation (V&V) is a disciplined
approach to assessing software products throughout the
product life cycle. A V&V effort strives to ensure that
quality is built into the software and that the software
satisfies user requirements" (IEEE-1059-93).
Both the
verification process and the validation process begin early
in the development or maintenance phase. They provide
an examination of key product features in relation both to
the products immediate predecessor and to the
specifications it must meet.
- VALIDATION (Chap. 22 & 24 of textbook,
Ref. 3 , and
Ref. 4
):
Validation is used to make we "are
building the right product." That is, are we meeting the
customers needs?
"Software Verification and Validation (V&V) is a disciplined
approach to assessing software products throughout the
product life cycle. A V&V effort strives to ensure that
quality is built into the software and that the software
satisfies user requirements" (IEEE-1059-93).
Validation is an
attempt to ensure that the right product is built, that is, the
product fulfills its specific intended purpose. Both the
verification process and the validation process begin early
in the development or maintenance phase. They provide
an examination of key product features in relation both to
the products immediate predecessor and to the
specifications it must meet.
STANDARDS:
Each group will need to address and follow the appropriate
standards documents.
SCHEDULE:
Each group will need to finsh their initial documents
and give an oral report on the dates shown below:
- Requirements: Feb. 6 *** NOTE MODIFIED DATES! ***
- Design Presentation: Feb. 20
- Coding Presentation: Mar. 20
- Testing Presentation: Apr. 6
- Time during class to meet in groups, Apr. 17
- Blue Team Testing of Vehicle and Software, April 20 (at Foundry Park)
If weather is bad, we will do this in the classroom, please watch your email for announcements.
- White Team Testing of Vehicle and Software, April 22 (at Foundry Park)
If weather is bad, we will do this in the classroom, please watch your email for announcements.
- Time during class to meet in groups, Apr. 24
- White Team mine finding system demonstration test (at Foundry Park), Apr. 27
If weather is bad, we will do this in the classroom, please watch your email for announcements.
- Blue Team in-class mine finding system demonstration test (at Foundry Park), Apr. 29
If weather is bad, we will do this in the classroom, please watch your email for announcements.
- Blue and White Teams V&V Presentation: May 1
BUT: New item to address: The customer has now decided that they
want to add an odometer to the vehicle (ie a way to keep track
of the X-Y position of the vehicle from the motor and steering
input time histories. The V&V teams has to address the V&V of
the entire project with a discussion of how all the various parts of
the project will need to be changed to address this new requirement.
They wil need to address whether the project has met all the
requirements and customer needs as well.
- Complete report including all group reports for each team, all documentation, code, test results, time worked records, etc. due May 1
For the group presentations,
each group will get 25 minutes on the above dates.
You will need to spend roughly 5 minutes describing what
your group was expected to do (e.g. describe what a
Requirements Group does), and 15 minutes describing
your report, and leave 5 minutes for questions.
Your work will not be done on the above dates however,
since each group will need to continue to interact
with the other groups.
Each group needs to keep track of the hours worked
by everyone in the group each week, and this needs to
be in the group report.
This needs to be accurate, we don't care what the numbers
are as long as it is accurate. This will help us
estimate total project costs.
This is a tight schedule, so the groups will need to
work hard to finish their portion of the project on time
and it must be done well.
STUDENTS AND GRADING:
- The class will be divided into two teams (the "Blue" and
the "White" teams), so that at the end of
the semester we will have two sets of all the documents and
two sets of software. We will have a competition to see which
teams system works best at the end of the semester.
So there will be some ethics and professionalism required
to keep the projects separate and the ideas and documents secure.
- Each student needs to decide which group they want to be in,
and I will try to honor those requests. Each student needs
to give me (on friday, Jan. 23) a list of their top three
group choices. [the group and teams have been formed,
and listservs (440blue@lists.psu.edu and 440white@lists.psu.edu)
have been established
for each team. All students should have received an email notification.]
- Grading will be based upon team documents, record keeping,
interactions with other teams, oral presentations,
and final competition.
REFERENCES:
- Long, L.N., Sharma, A., and Souliez, F.,
"
Client-Server Java
Programming for Wireless Mobile Robots," AIAA Paper 2003-0459,
AIAA Aerospace Sciences Meeting, Reno, NV, Jan., 2003.
- Sommerville, I., Software Engineering, 8th Edition.
-
Software Engineering Body of Knowledge (SWEBOK)
-
Gentle Introduction to Software Engineering
Software Technology Support Center, USAF, Hill Air Force Base
-
Others...
Return to Course Syllabus
Maintained by:
Prof. L. N. Long, 233 Hammond Bldg.
source : http://www.personal.psu.edu/lnl/440pub/project/
Copyright, 2008
Last modified: Wednesday, 15-Apr-2009 13:08:42 EDT
Hits since Jan. 18, 2009
|
