Assignment 01
Name: Fazal Wadood
Student ID: CSC-23S-186
Class-Section: CS-5B
Department: Computer Science
Semester: 5th Spring
Course: Software Engineering
Course Code: SEN 102
Instructor: Ms. Samreen Javed
Date: 09-March-2025
Qno:o1
Write any 3 scenarios and case studies for Software Engineering with
proper headings and their solutions with required diagrams.
Case Study-01: Virtual Case File (VCF) System
_________________________________________________________
Project Definition
The Virtual Case File (VCF) system was a software application developed by the
Federal Bureau of Investigation (FBI) between 2000 and 2005. It was intended to
modernize the FBI's outdated case management system by replacing the legacy
Automated Case Support (ACS) system. The primary goal was to enhance the
FBI's ability to manage and share case information effectively across the
organization.
Requirements Analysis
Functional Requirements:
● User-friendly interface for agents to access and manage case files
● Secure data storage and sharing across FBI departments
● Integration with hardware and network upgrades
Non-Functional Requirements:
● Security: Ensure classified information remains protected
● Scalability: Support thousands of agents accessing the system
concurrently
● Performance: Optimize data retrieval and reporting times
Design
The system was designed as part of the Trilogy program, which focused on:
● Hardware Upgrades: Modernizing existing computer systems
● Network Infrastructure: Establishing secure, high-speed networks
● VCF Software: Developing a streamlined interface for investigative
processes
Program Implementation
● Frontend: Web-based interface for agent interaction
● Backend: Proprietary systems for processing case data
● Database: Secure data storage for case files and agent activity logs
● Integration: Hardware and network upgrades aligned with Trilogy program
requirements
Component Testing
● Unit Testing: Focused on verifying individual modules, such as login
authentication and file retrieval
● Validation: Ensured secure handling of classified data
Integration Testing
● Tested interactions between hardware, network, and VCF software
● Verified seamless communication between case management interfaces
and data storage
System Testing
● Load Testing: Simulated thousands of agents accessing the system
simultaneously
● Security Testing: Checked for vulnerabilities in handling sensitive FBI
information
● Usability Testing: Assessed user experience for field agents using the
interface
System Delivery
● Deployment: Implemented system-wide installation without phased
deployment
● Training: Conducted briefings and distributed user manuals for agents
● Feedback: Gathered agent responses post-implementation
Maintenance
● Corrective Maintenance: Attempted to fix bugs and errors post-launch
● Adaptive Maintenance: Addressed changing investigative needs
● Perfective Maintenance: Planned updates to enhance user experience
Challenges and Lessons Learned
● Lack of Clear Technical Architecture: Poor initial planning led to flawed
design decisions
● Frequent Specification Changes: Continuous updates caused scope
creep
● Management Turnover: Repeated leadership changes created
inconsistent project direction
● Inadequate Technical Expertise: Insufficient computer science
knowledge among personnel hampered progress
● Deployment Strategy Issues: A full-scale system overhaul made
incremental testing difficult
Outcome
The VCF project was abandoned in April 2005 after nearly $170 million in
expenses. The FBI continued using the outdated ACS system until a new
initiative, Sentinel, was introduced. This case underscores the importance of
structured software engineering processes, consistent leadership, and technical
expertise for large-scale software projects.
________________________________
Case Study-02: Expeditionary Combat Support System
(ECSS)
__________________________________________________________
Project Definition
The Expeditionary Combat Support System (ECSS) was a software project
started by the United States Air Force (USAF) from 2005 to 2012. The goal was
to create one big computer program to help the Air Force manage its equipment
— like airplanes, fuel, and spare parts — by replacing over 200 older systems
with just one.
Requirements Analysis
Functional Requirements:
● Track airplanes, fuel, and spare parts in one system
● Allow staff to check inventory quickly
● Connect different Air Force departments so they share information easily
Non-Functional Requirements:
● Security: Keep military information safe
● Speed: Ensure data updates happen fast
● Reliability: The system should work without crashing
Design
The plan was to use ready-made software from Oracle (called COTS software)
and have another company, CSC, set it up and connect it to the Air Force’s old
systems.
Program Implementation
● Frontend: A simple web interface for staff to log in and check equipment
● Backend: Oracle’s ERP software
● Database: A central database for all military assets
Component Testing
● Unit Testing: Tested how the login, inventory search, and report creation
worked on their own
● Validation: Made sure only authorized staff could access data
Integration Testing
● Checked if Oracle’s software and the old Air Force systems could work
together
● Ensured data flowed correctly between asset tracking and reporting
System Testing
● Load Testing: Simulated thousands of staff using the system at once
● Security Testing: Ensured hackers couldn’t break into the system
System Delivery
● Deployment: Tried launching the full system at once instead of step by
step
● Training: Gave staff manuals to learn how to use the new system
Maintenance
● Corrective Maintenance: Fixed bugs after testing
● Adaptive Maintenance: Planned updates for new Air Force needs
Challenges and Lessons Learned
● Too Complex: Replacing 200 old systems at once made the project very
hard
● Unclear Plan: The team kept adding new ideas, so the project kept
growing
● Vendor Issues: Oracle and CSC didn’t always work smoothly together
● Change Resistance: Air Force staff found it hard to switch from old
systems
Outcome
After spending $1.1 billion, the ECSS project was canceled in 2012. It didn’t help
the Air Force in the way it was supposed to, and they decided it would take even
more money and time to fix it. This shows how important it is to have clear goals,
work in steps, and plan carefully when building big software systems.
_____________________________________
Case Study-03: Blizzard's Titan Project
_______________________________
Project Definition
Blizzard Entertainment, famous for games like World of Warcraft, started working
on a new online game called Titan around 2007. The goal was to create a
massive multiplayer online game (MMO) that would be even bigger and better
than World of Warcraft. They wanted Titan to have a new world, new characters,
and exciting missions for players.
Requirements Analysis
Functional Requirements:
● Create a large virtual world for multiplayer interaction
● Include missions, quests, and team-based gameplay
● Support character customization and progression
Non-Functional Requirements:
● Scalability: Handle thousands of players at the same time
● Security: Protect player data and game servers
● Performance: Ensure smooth gameplay with minimal lag
Design
The game was planned to have a futuristic setting with both player-versus-player and
player-versus-environment modes. The design included:
● World Building: Creating vast maps and cities
● Character Systems: Allowing players to customize and level up their
characters
● Game Engine: Developing or modifying a game engine to support MMO
features
Program Implementation
● Frontend: User interface for login, character creation, and gameplay
● Backend: Game engine managing physics, AI, and multiplayer
interactions
● Database: Storing player profiles, game progress, and virtual items
Component Testing
● Unit Testing: Checked login, quest progress, and combat mechanics
separately
● Validation: Ensured character data was correctly saved and loaded
Integration Testing
● Verified smooth interaction between character systems, quests, and the
game world
● Tested multiplayer features to check real-time updates between players
System Testing
● Load Testing: Simulated thousands of players logging in and playing at
once
● Security Testing: Ensured game servers were safe from hacking
● Usability Testing: Gathered feedback on how fun and smooth the game
felt
System Delivery
● The project aimed for internal beta testing first, inviting a small group of
players to try the game and give feedback
● Blizzard planned for a public release after resolving major bugs and
balancing the gameplay
Maintenance
● Corrective Maintenance: Planned to fix bugs reported during beta tests
● Adaptive Maintenance: Expected to release updates with new content
and missions
● Perfective Maintenance: Aimed to add new features to keep players
engaged
Challenges and Lessons Learned
● Unclear Vision: The team struggled to agree on what Titan should be,
making development slow
● Technical Issues: Building a huge game world with complex mechanics
caused unexpected bugs
● Overambitious Goals: The scope was too large, making it hard to
manage and complete
Outcome
In 2014, Blizzard canceled Titan after spending about $80 million, realizing the
project wasn’t coming together as planned. However, they didn’t let the effort go
to waste. Many ideas from Titan were used to create Overwatch, a new game
that became a big hit. This case teaches us that even failed projects can inspire
successful ones if you learn from the experience.
Qno:02 What are the techniques for software process models?
In software engineering, process models are like roadmaps that guide how
software is planned, built, and delivered. Different techniques suit different types
of projects. Let’s explore the main ones:
1. Waterfall Model
This is the simplest model. It works step by step — first, gather
requirements, then design, code, test, and finally deploy. You can’t move to
the next step until the current one is done.
○ Best for: Small, straightforward projects.
○ Limitation: If you realize a mistake later, it’s hard to go back and fix
it.
2. Incremental Model
Imagine building a house room by room instead of all at once. In this
model, the software is developed and delivered in small parts (increments).
Each part adds new features until the final product is ready.
○ Best for: Projects where you want to release a basic version first
and add more features over time.
○ Limitation: Poor planning can cause the pieces not to fit together
well.
3. Spiral Model
This model focuses on repeating four main phases — planning, risk
analysis, development, and review — over and over. Each cycle adds
improvements until the software is complete.
○ Best for: Large, high-risk projects with lots of unknowns.
○ Limitation: It’s complex and can be costly because of continuous
revisions.
4. V-Model (Verification and Validation Model)
An extension of the waterfall model, this one focuses heavily on testing.
Every development phase (like design or coding) has a matching test
phase (like system testing or unit testing).
○ Best for: Projects where quality and testing are top priorities.
○ Limitation: Doesn’t adapt well to changing requirements.
5. Agile Model
Agile is all about flexibility. Instead of waiting until the end to show the
software, small pieces are developed in short cycles (called sprints) with
regular customer feedback.
○ Best for: Projects with changing needs or client feedback.
○ Limitation: Needs strong teamwork and communication to succeed.
6. Prototype Model
In this model, a simple version (prototype) of the software is quickly built to
show users. Their feedback helps shape the final product.
○ Best for: When users need to "see" how the software will work
before finalizing everything.
○ Limitation: Too much feedback can slow down progress.
7. RAD Model (Rapid Application Development)
This focuses on speed. Developers reuse existing components and gather
feedback quickly, reducing the time needed to build the software.
○ Best for: Projects with tight deadlines.
○ Limitation: Requires experienced developers to handle the fast
pace.
Qno:03 How can you define the functional and nonfunctional requirements
with daily life examples?
In software engineering, requirements describe what a system should or
shouldn’t do. These are divided into two main types:
1. Functional Requirements
These describe what the software must do — the features and tasks it performs.
They focus on the system’s behavior and functionalities.
Daily Life Example:
Imagine a mobile food delivery app. Some functional requirements could be:
● User registration: Users should be able to sign up using their email or
phone number.
● Search feature: The app must let users search for restaurants by name or
cuisine.
● Order placement: Users should be able to add food to their cart and place
an order.
● Payment processing: The app must allow secure payment through credit
cards or e-wallets.
In short: Functional requirements are all about what the system does — like
logging in, searching, or making payments.
2. Non-Functional Requirements
These define how the system should perform. They don’t add new features but
set quality standards — like speed, security, and usability.
Daily Life Example:
Let’s go back to the food delivery app. Some non-functional requirements could
be:
● Performance: The app should load the search results within 2 seconds.
● Scalability: It must handle 10,000 users ordering at the same time during
peak hours.
● Security: All payment data should be encrypted to prevent hacking.
● Usability: The app should have a simple, easy-to-navigate interface.
In short: Non-functional requirements are about how well the system works —
like being fast, secure, and user-friendly.
