Portfolio Requirements

The portfolio is required as part of the CIS 895 course. There are items required in the portfolio and expectations that students will do more than the minimal requirements in a number of areas. 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 supervisory committee.

Purpose of the portfolio

The purpose of the portfolio is to demonstrate the student's ability in all phases and activities of software development. Contents are examples of the student's activities in those phases and activities. It is expected that use of state-of-the-practice tools and methodologies — such as CASE tools, testing tools, and formal methodologies — will be evident. The student’s professionalism 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 the prior presentation has been satisfactorily completed. There will be at least one month between each presentation.

Required documentation

  1. 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 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 viewed as a record of the student's activities on this project. Each time period 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

  1. Vision document – There will be two parts to the vision document —project overview and 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 attribute, 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, 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.

  1. 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 – This 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 names of at least two MSE students who have agreed to participate in the formal technical inspection.

  1. 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.
  2. Software quality assurance plan – The student will create an 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

  1. Action items – Action items identified during Presentation II, along with the efforts made to satisfy them, will be documented.
  2. Vision document – The vision document will be updated to provide a complete representation of all requirements. These will be ranked according to importance and a set of “critical” requirements identified.
  3. 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.
  4. Cost estimate – The document will also provide an updated estimate on the size, cost and effort required for project implementation.
  5. Implementation plan – The implementation plan will define 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.
  6. Formal requirement specification – One part of the project will be formally specified using a published, formal methodology such as OCL.
  7. Architecture design – The complete architectural design will be documented using appropriate diagrams such as class and object diagrams, sequence/collaboration diagrams, state chart/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.
  8. Test plan – A plan will be developed for the project to address the required tests to show 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, types of tests that will be used for these test cases, data that will be used for each case and requirement traces for each test case.
  9. 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.
  10. Executable architecture prototype – Prior totPresentation 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.
  11. In addition, the student must participate as a technical inspector for two other MSE students before his or her portfolio can be approved by the committee (see item 21 below).

Presentation III – implementation

  1. Action items – Action items identified during Presentation II, along with the efforts made to satisfy them, will be documented.
  2. User manual -– A user manual will be provided. Sections will include (if appropriate) an overview and explanations of common usage, user commands, error message, and data formats.
  3. Component design – The internal design of each component will be documented. The documentation required will be consistent with the complexity of the individual components. Use of model-based diagrams such as class diagrams, sequence/collaboration diagrams and state chart/activity diagrams will be considered.
  4. Source code – A well-documented source code will be submitted. This code will correspond directly to the architecture and component design.
  5. 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.
  6. Project evaluation – The student will review the project. The process will be reviewed, including usefulness of the methodologies used, accuracy of the estimations and 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.
  7. References – The annotated bibliography will include cited references for all notations used in the portfolio.
  8. Formal technical inspection letters – The student must include letters from two other MSE students stating that he or she has successfully participated in the other student's MSE projects as an inspector, and that their projects had successfully passed the architecture presentation (or at least its formal technical inspection section).