What This Document Is
This is a Feasibility Evidence Description (FED) – a critical planning deliverable from a Software Engineering course at the University of Southern California (CSCI 577). Specifically, it represents the initial front-end design plan developed by Team 01 for a project focused on improving communications and project tracking tools for the Thai CDC. The FED outlines the team’s approach to assessing the viability of their proposed software solution, laying the groundwork for subsequent development phases. It details the team’s roles, responsibilities, and initial considerations regarding the project’s technical and operational feasibility.
Why This Document Matters
This document is invaluable for students studying software engineering, systems analysis, or project management. It serves as a prime example of how to formally evaluate the practicality of a software project *before* significant resources are invested. Individuals involved in the early stages of software development – including analysts, architects, and project managers – will find this particularly useful. It’s especially relevant when needing to demonstrate due diligence and justify project decisions to stakeholders. Understanding the structure and content of a FED is crucial for anyone aiming to contribute to successful software project initiation.
Common Limitations or Challenges
This FED represents a snapshot in time – an early-stage assessment. It does *not* contain detailed code, functional specifications, or user interface designs. It focuses on the ‘why’ and ‘if’ of the project, not the ‘how’. The document outlines evaluation criteria and potential strategies, but doesn’t present definitive solutions or implementation details. It’s a high-level overview intended to inform further development, and therefore won’t provide a complete picture of the final software product.
What This Document Provides
* A clear definition of the project’s scope and objectives.
* Identification of team members and their respective roles.
* A version history tracking changes and rationale.
* A comprehensive table of contents for easy navigation.
* A framework for evaluating architectural models.
* Initial assessments of service level requirements.
* Preliminary considerations regarding hardware and software costs.
* Tables outlining evaluation criteria for key project attributes and features.
* Evidence related to the feasibility of project capabilities and evolution.
