|
| |
Portfolio (Distance Education)
Applicable for all
MSE students that file a POS after August 15, 2002.
(Click
here for printer friendly PDF version)
Requirements for the Portfolio
This document is intended as a guide to developing a portfolio in partial
fulfillment of the masters of software engineering degree. The portfolio is
required as part of the CIS 895 course. There are items that are required in
the portfolio and expectations that students will do more than the minimal
requirements in a number of areas. The products in the portfolio will be
supplemented with oral presentations (after items 2 - 5, 6 - 13, and 14 -
21). The final evaluation of the portfolio rests with the major professor
and the supervisory committee.
The following Tegrity presentations provide detailed guidance.
Purpose of the Portfolio
The purpose of the portfolio is to demonstrate the student's ability in
all phases and activities of software development. The contents are examples
of the student's activities in those phases and activities. It is expected
that the use of state-of-the-practice tools and methodologies, such as CASE
tools, testing tools, and formal methodologies, will be evident. The
professionalism of the student should be evident in these examples. The
portfolio may represent work on one major project, or with the agreement of
the major professor and supervisory committee, a series of related projects.
Documentation Requirements
The following section describes the minimal set of documents that must be
contained in the portfolio. It is expected that additional effort will be
made in some of the areas based on the nature of the project. The major
professor and committee must approve those areas. Each document will be made
available to the via a project web page. The web page will maintain the
current version of the document as well as all previous major versions.
Major versions are those that have been given to the student’s major
professor or any committee member for review.
Each project will have at least three presentations. The student will
give each presentation to the committee over a specific set of documents.
The student should not begin work on the next phase until the committee has
agreed that the presentation has been satisfactorily completed. There will
be at least one month between each presentation.
Required Documentation
-
Engineering Notebook - As software engineering
struggles to become more professional, it becomes obvious that individual
software engineers need to know more about their own work. A standard
approach in engineering is the maintenance of an engineering notebook that
records activities and effort. This notebook will be a record of the
effort involved in the project both in terms of ideas and in terms of
effort. As suggested by Watts Humphries, we will keep track of the
quantity of our own effort in projects. This part of the engineering
notebook will be as a record of the student's activities on this project.
Each time spent on the project will be recorded along with a description
of the phase and activity. Because of the importance of errors, each
failure will be logged as well as the effort spent identifying and
removing the fault.
Presentation I – Objectives
-
Vision Document – There will be two parts to
the vision document: the project overview and the requirements.
-
Overview – This section will include an
overview of the project, its purpose, goals, risks, constraints, and
direction. It will also discuss the main product features, quality
attributes, and external interfaces.
-
Requirements Specification – At this
point, the requirements specification will capture the main or
“driving” requirements of the project. Model based techniques such
as use cases or dataflow diagrams are appropriate. The requirements will
describe all key functionality required of the resulting system. At a
minimum, the requirements will include the valid range of inputs and the
expected outputs associated with those inputs. Each requirement will
also be given a unique identifier. This document will continue to evolve
at least until the architecture presentation and will be continually
updated.
-
Project Plan - The project plan will detail
the phases, iterations, and milestones that will comprise the project.
Each deliverable will be included in the plan with estimated dates,
sign-offs and evaluation criteria. PERT or Gantt charts are appropriate
inclusions in this plan.
-
Cost Estimate - The document will also
provide a detailed estimate on the size, cost and effort required for
the project. At the conclusion of the project, the estimation effort
will be critiqued.
-
Architecture Elaboration Plan – The
Architecture Elaboration plan will define the activities and actions
that must be accomplished prior to the Architecture Presentation. The
plan must include the set of requirements to be formalized and the
artifacts that will undergo formal technical inspection. The plan will
also include the names of at least two MSE students that have agreed to
participate in the formal technical inspection.
-
Demonstration – The student will demonstrate
at least one executable prototype, simulation, or other such
representation that establishes the feasibility of the important or risky
elements of the requirements. Projects with a graphical user interface
will include an executable prototype of the user interface.
-
Software Quality Assurance Plan – The
student will create a SQA Plan that describes the required documentation,
standards and conventions, test tracking and problem reporting, and tools
used during the project. The plan will also identify the set of quality
metrics used to assess product reliability.
Presentation II – Architecture
-
Action Items – Action items identified
during Presentation II, along with the efforts made to satisfy them, will
be documented.
-
Vision Document – The Vision Document will
be updated to provide a complete representation of all requirements. These
requirements will be ranked according to importance, and a set of
“critical” requirements identified.
-
Project Plan - The project plan will detail
the phases, iterations, and milestones that will comprise the project.
Each deliverable will be included in the plan with estimated dates,
sign-offs and evaluation criteria. PERT or Gantt charts are appropriate
inclusions in this plan.
-
Cost Estimate - The document will also
provide an updated estimate on the size, cost and effort required for
the project implementation.
-
Implementation Plan – The Implementation
plan will define the activities and actions that must be accomplished
during implementation. The plan will include a Work Breakdown Structure,
complete with time and costs estimates and completion criteria.
-
Formal Requirement Specification - One part of
the project will be formally specified using a published, formal
methodology such as OCL.
-
Architecture Design - The complete
architectural design will be documented using appropriate diagrams such as
class and object diagrams, sequence/collaboration diagrams,
statechart/activity diagrams, hierarchy diagrams, etc. Each component in
the architecture will be documented at the interface level. Reuse of
commercial, or pre-existing components will be documented.
-
Test Plan - A plan will be developed for the
project to address the required tests to show that the product satisfies
the requirements. The plan will include evaluation criteria for all
critical use cases and a set of test data deemed adequate for acceptance
testing. Specifically, the test plan will identify a set of test cases,
the types of tests that will be used for these test cases, the data that
will be used for each case, and the requirement traces for each test case.
-
Formal Technical Inspection - One of the
technical artifacts (design, formal requirement, or executable prototype)
will be subjected to a formal technical inspection by at least two
independent MSE students (inspectors). A formal checklist to be used by
the inspectors will be prepared by the student. Each independent inspector
will provide a report on the result of their inspection, which will
contain, at a minimum, a cover letter and the annotated checklist. These
reports will become part of the project documentation.
-
Executable Architecture Prototype – Prior to
the Presentation II, an executable architecture prototype will be built in
one or more iterations. The prototype will address all critical
requirements identified in the vision document and expose the top
technical risks.
Presentation III – Implementation
-
Action Items – Action items identified
during Presentation II, along with the efforts made to satisfy them, will
be documented.
-
User Manual - A user manual will be provided.
Sections will include (if appropriate) an overview and explanations of
common usage, user commands, error messages, and data formats.
-
Component Design – The internal design of
each component will be documented. The documentation required will be
consistent with the complexity of the individual components. The use of
model-based diagrams such as class diagrams, sequence/collaboration
diagrams, and statechart/activity diagrams will be considered.
-
Source Code - Well-documented source code will
be submitted. This code will correspond directly to the architecture and
component design.
-
Assessment Evaluation - The documentation will
include a document detailing the testing done on the project. Included
will be descriptions of the testing, failures, and reliability estimates.
Graphical methods will be used, e.g. error rate diagrams, etc.
-
Project Evaluation - The student will review
the project. The process will be reviewed, including the usefulness of the
methodologies used, the accuracy of the estimations, and the usefulness of
the reviews. Similarly, the product will be reviewed and evaluated for
whether it accomplishes the ideas presented in the initial overview and
for the quality of the product.
-
References – The annotated bibliography will
include cited references for all notations used in the portfolio.
-
Formal Technical Inspection Letters – The
student must include two letters from other MSE students stating that the
student in question successfully participated in their MSE project as an
inspector and that their projects (or at least their formal technical
inspection section) had successfully passed the architecture presentation.
| |
|
