Intent:

Motivation:

Applicability:

Structure:

1. Each team chooses a project from any domain of interest. Projects may target banking, insurance, a doctor's practice, a pharmacy, game etc.
2. Each team is responsible for finding a person from that domain who is willing to act as the domain expert. It is preferable to choose an expert who is interested in reaching a complete software product because such an expert would be willing to invest the time necessary to to reach sound user requirements, to provide feed back in intermediate stages as well as to determine the validity of the final product.
3. Each team conducts a series of interviews with their domain expert (at the experts work place) to determine requirements definition that could include functional and non functional requirements.
4. Each team submits these requirements to the instructor for evaluation. Evaluation would be made to ensure that these requirements are sufficient to start the next stage.
5. Each team rewrites the requirements guided by the instructor's evaluation and after re-consultation with the domain expert.
6. Each team starts with the analysis phase using an OO methodology.
7. Outputs from the analysis phase are submitted to the instructor for evaluation. The evaluation would be made to ensure that:
   
   • The concepts were applied correctly.
   • The outputs are consistent with user requirements.
   • The outputs are at an appropriate level of abstraction.
   • The outputs do not make commitments to a specific implementation.
8. Each team amends outputs of the analysis phase guided by the evaluation.
9. Each team starts on the design phase.
10. Outputs from the design phase are also submitted to the instructor for evaluation. The evaluation would be made to ensure that outputs of the analysis phase were unfolded consistently to the right level of detail.
11. Each team implements the design.
12. Each team demonstrates the produced software for the domain expert for validation purposes.
13. Each team modifies the implementation based on step 12.
14. Finally each team supports a report that includes the outputs of each phase. In addition the report includes:
    
    • A user manual for the developed product.
    • A description of the test cases that were used to verify the produced software.
    • A self assessment component that discusses the validity of the implementation against user requirements as well as the team's experience.
    • A letter from the domain expert assessing the product from her/his own perspective.

    Setting due dates and having students abide by these is essential. Grading and assessment of such a project would be based on the submitted report and on the validity of the outputs of each phase of the development. Students in the same team may get different grades.

    Consequences:

    • Students practice the concepts and methods taught to problems in real work environments. This helps to enforce the viability of concepts and methods taught and to introduce students to industrial work experience.
    • By involving a domain interest, students are motivated to finish the target project with a matching interest to learn the material introduced during lecture hours.
    • Demonstrating the finished project for a domain expert enforces issues of validation vs. verification.
    • Working in teams of 2-3 helps to elucidate issues related to team and team work and gives a fair chance to reach a complete product.
    • Abiding by due dates in producing the ouputs of different phases and a complete report on the developmet process is essential to reinforce issues related to project planning, scheduling etc.
    • Producing a complete report from A to Z emphasizes issues related to project documentation and project maintainance.
    • Grading students within a team independently mimics to a large extent staff evaluation where staff members are evaluated, promoted etc. independently of their colleagues.

    Implementation:

    1. The project must be of the right size and appropriately focused to finish in a one semester course.
    2. The availability of a domain expert who is willing to offer the time is essential.
    3. The contents of the lectures must be suitably timed to proceed ahead of the different phases of the project.
    4. The assesment of the instructor of the outputs of different phases is made to focus the students on the target task and to ensure that the concepts have been assimilated and applied correctly.

    Example Instances:

    This pattern has been used repeatedly in an OO Software Engineering course.

    Related Patterns:

    This pattern is related in theme to the Preparation, Industrial Presentation and Roundtable (PIPL) Pattern. (#15)

    ---

    Home	Project Leaders	Pedagogical Pattern Format	Evolution of a pedagogical pattern	Sample Patterns	Publications
    Subject Index	Learning Obj. Index	Teaching/Learning Element Index	Alphabetical Index	Author(s) Index	Contact Us

    Previous pattern

    Search This Site

    Next pattern