Welcome to Evaluating an Event Driven Application
Welcome to the final, crucial chapter of your AS 2: Event Driven Programming journey! If you have built an event-driven graphical application in C# / .NET, you might feel like your work is finished once the code compiles. However, in the CCEA Software Systems Development portfolio (which accounts for 50% of your AS Level and 20% of your total A Level), the Evaluation is where top marks are secured.
Don't worry if evaluation seems daunting at first. Think of evaluation like being a professional food critic or a car reviewer: you are not just describing what the car looks like or listing its parts; you are testing how smoothly it drives, judging whether it meets the buyer's needs, identifying where it rattles, and explaining how the next model could be engineered better.
1. Evaluating Against User Requirements and Design Specifications
The primary goal of your event-driven software is to solve the problem set out in your initial user requirements. Your evaluation must provide hard, objective proof that you met these targets.
A. The Requirement Traceability Matrix
A Requirements Matrix is a structured review that cross-references every single functional requirement (e.g., "The user can calculate total invoice cost on button click") and non-functional requirement (e.g., "The system responds to user events within 1 second") against your finished application.
For each requirement, you must evaluate whether it is:
• Fully Met: The feature is implemented, connected to the correct event handlers, and works perfectly.
• Partially Met: The feature works under certain conditions but lacks full functionality (for example, calculation works, but does not display currency formatting).
• Omitted / Not Met: The feature was dropped or could not be completed, requiring a clear justification of why.
B. Test Plan Validation as Objective Evidence
You cannot simply write: "My save button works perfectly." You must validate this claim using documented test evidence from your test plan. A robust evaluation explicitly links features back to three specific types of test data:
1. Normal Test Data: Typical, valid data (e.g., entering an age of \(25\)) to prove event handlers execute expected logic successfully.
2. Boundary / Extreme Test Data: Data at the absolute limits of acceptable ranges (e.g., entering an age of \(18\) or \(65\) if the valid range is \(18\) to \(65\)) to demonstrate that edge-case event logic fires accurately.
3. Errant / Invalid Test Data: Data that is completely unacceptable (e.g., entering text into a numeric field, or leaving mandatory text boxes blank) to prove that validation checks and error handlers intercept the event gracefully.
C. The Client's Perspective
An application might be technically sound to a developer, but unusable for the intended user. You must evaluate the software from the end-user's viewpoint: Is the software truly fit-for-purpose? Does the graphical user interface (GUI) simplify their daily workflow, or does it cause confusion?
Section Key Takeaway: Never just state that a requirement is met. Always substantiate your claim by referencing specific results from your normal, boundary, and errant test runs.
2. Evaluating Software Quality and Technical Robustness
Evaluating an event-driven system requires looking under the hood at both the visual interface and the underlying code architecture.
A. Human-Computer Interaction (HCI) and GUI Usability
In event-driven programming, the user interacts through triggers like button clicks, dropdown menu selections, and text changes. Evaluate your GUI against established HCI principles:
• Visual Layout & Form Navigation: Is the visual flow logical (e.g., top-to-bottom, left-to-right)? Is the tab index set correctly so users can navigate fields using the keyboard?
• Intuitive Event Triggers: Are buttons, menus, and controls clearly labelled and placed where users intuitively expect them?
• Visual Consistency: Are color palettes, font families, and button styles standardized across all forms?
• Input Masking: Are sensitive inputs (such as passwords) or formatted inputs (such as telephone numbers or dates) masked properly?
• User Feedback Messages: Does the system communicate clearly through informative message boxes, status labels, or progress indicators when an event completes or encounters an issue?
B. Exception Handling and Validation
An event-driven program is prone to unexpected user actions at any moment. Your evaluation must analyze how resilient the system is when events fire:
• Field-Level and Form-Level Validation: Did your validation routines intercept invalid types, empty values, or out-of-range inputs before they could corrupt your data?
• Structured Exception Handling: How effectively did you use try-catch-finally blocks? When runtime errors occur (such as a missing file or an invalid numerical parse), does the application catch the error gracefully, or does it crash?
C. Maintainability and Coding Standards
Imagine another programmer inheriting your C# solution tomorrow. How easily could they understand and update it?
• Separation of Concerns: Did you separate your GUI event-handling code from your core business logic and Object-Oriented (OOP) classes? (GUI forms should capture events and display results; OOP classes should handle calculations and data structures).
• Meaningful Identifiers & Self-Documenting Code: Are controls and variables clearly named (e.g., txtCustomerSurname or btnCalculateTotal rather than generic names like Button1)?
• Data Persistence: How effectively does the system persist data between sessions (e.g., using text file I/O or object serialization)?
Section Key Takeaway: High software quality relies on clean separation: keep your event listeners in the form layer and your business logic in modular OOP classes, protected by robust validation and try-catch-finally blocks.
3. Self-Evaluation and Future Enhancements
A critical developer is honest about their project management and recognises that no first-iteration application is completely final.
A. Personal Performance Review
Reflect critically on how you managed the development lifecycle:
• Time Management & Planning: Did you meet your planned project milestones? If deadlines slipped, why did it happen?
• Problem-Solving Hurdles: What technical bugs or logic hurdles did you encounter during event handling or file persistence, and what strategies did you use to overcome them?
• Deviations from Plan: Where did your final application diverge from your initial design, and what technical reasons justified those changes?
B. Identifying Limitations & Recommending Future Improvements
Avoid generic statements like "I would make the buttons prettier." CCEA examiners look for realistic, substantive, and technical enhancements:
• Refactoring Event Logic: Streamlining duplicated event handlers into reusable methods or custom delegates.
• Database Integration: Moving from flat-file persistence or serialization to a fully relational database management system (a natural progression towards your A2 unit).
• Enhanced Security & Validation: Implementing advanced password hashing or multi-level user permissions.
• Advanced UI Components: Upgrading basic controls to dynamic data grids or dashboard summaries.
Section Key Takeaway: Strong self-evaluations highlight both triumphs and struggles, providing realistic technical enhancements rather than superficial cosmetic tweaks.
4. Pitfalls to Avoid in Your Coursework Evaluation
To achieve the highest marks in your AS 2 portfolio, keep these common examiner warnings in mind:
• Pitfall 1: Writing Descriptively Instead of Evaluatively
Poor approach: "I created a form with three textboxes and a button. When clicked, it calculates the discount."
Evaluative approach: "The discount event handler successfully calculates rates according to Requirement 3.2. Evidence from Boundary Test Case 4 confirms that orders exactly at the £100 threshold receive the specified 10% reduction without rounding errors."
• Pitfall 2: The "100% Bug-Free" Claim
Never claim your program is completely flawless. Software engineering recognizes that all systems have limitations under extreme conditions. Acknowledge your system's edge-case limitations honestly.
• Pitfall 3: Conflating GUI Events with OOP Logic
Ensure you do not mix up user interface actions (e.g., SelectedIndexChanged, btnSubmit_Click) with the internal operations of your class objects (e.g., class constructors, getters/setters, calculation methods).
Quick Revision Checklist
Before submitting your evaluation section, ensure you have addressed every component:
• Matched all functional and non-functional requirements in a Requirements Matrix.
• Linked evaluation statements to Normal, Boundary, and Errant test results.
• Assessed the GUI from the client's perspective and against HCI usability principles.
• Evaluated validation, exception handling (try-catch), and data persistence.
• Confirmed separation between event handlers and OOP class logic.
• Completed an honest personal performance review.
• Proposed meaningful, technical future enhancements (such as database integration for A2).