Software Configuration Management Plan (SCMP) Essentials

Posted on Jan 19, 2025 in Software Engineering

Comprehensive Sheet for SCMP (Software Configuration Management Plan)

The Software Configuration Management Plan (SCMP) is critical to maintaining control over project artifacts, ensuring consistency, traceability, and controlled evolution of the software. Here’s a step-by-step detailed breakdown into all essential sections, with examples and implementation details.

1. Introduction

Purpose:

• Define the goals of configuration management (CM) for the project.
• Establish processes and tools to control changes, versioning, and traceability.

Scope:

• Specifies the items under configuration control (code, documents, test cases, databases).
• Example:

  “This SCMP outlines CM processes for the Task Management System, covering code files, SRS, SDD, and deployment scripts to ensure consistency across all project phases.”

2. Configuration Identification

Purpose:

• Identify all items that need configuration management (CIs: Configuration Items).

Components:

1. Configuration Items (CIs):

   • Examples of CIs:
     • Source code files: main.py, user_auth.js.
     • Documentation: SRS, SPMP, SDD.
     • Test data and scripts: unit_tests_login.json.
     • Tools and configurations: IDE settings, Docker files.

2. Naming Conventions:

   • Follow consistent rules for names to ensure clarity.
   • Example:
     • Branch names: feature/*, bugfix/*.
     • Releases: release_v1.0.0, release_v1.1.0.
     • File versions: task_manager_v1.0.py.

3. Baseline Identification:

   • Define baselines for reference points.
   • Example:

     “Baseline v1.0 includes login and task management features fully implemented and tested.”

3. Configuration Control

Purpose:

• Define how changes are requested, reviewed, approved, and implemented.

Change Control Process:

1. Change Request:

   • A formal request to modify a CI.
   • Example Template:

     Change Request #123:
     - Description: Add 'Critical' priority level to tasks.
     - Impact: May require changes to the database schema.
     - Submitted by: John Smith (Developer).
     

2. Change Evaluation:

   • Steps:
     • Impact Analysis: Assess how the change affects code, testing, and deployment.
     • Example:

       “Adding ‘Critical’ priority requires updating database schema, backend APIs, and UI elements.”

3. Approval Workflow:

   • Responsible roles: Configuration Manager, Project Manager, Technical Lead.
   • Tools: Jira, Trello.
   • Example:

     “Changes must be approved by the Technical Lead before merging into the develop branch.”

4. Implementation:

   • Developers implement approved changes in feature branches.
   • Example:

     “Feature branch feature-critical-priority merged after successful code reviews and automated tests.”

5. Change Tracking:

   • Maintain a log of all changes.
   • Example Change Log Entry:

     Change Log #CR123:
     - Description: Added 'Critical' priority level to tasks.
     - Date: 2024-01-15.
     - Status: Completed.
     

4. Version Control

Purpose:

• Manage multiple versions of project artifacts to ensure consistency.

Tools:

• Git (or equivalent version control system).

Key Strategies:

1. Branching Model:

   • Main Branches:
     • main or master: Stable production-ready code.
     • develop: For integrating features under development.
   • Supporting Branches:
     • feature/*: For specific features.
     • bugfix/*: For urgent fixes.
     • hotfix/*: For emergency production fixes.

2. Tagging:

   • Assign tags to specific commits to mark releases.
   • Example: v1.0.0, v2.1.3-beta.

3. Merge Workflow:

   • Example: “All feature branches must pass automated tests and undergo code review before merging into develop.”

Example Git Workflow:

1. Create branch: git checkout -b feature-login.
2. Commit changes: git commit -m "Added login feature."
3. Push branch: git push origin feature-login.
4. Create PR: Merge into `develop` after approval.

5. Configuration Audits

Purpose:

• Ensure the project is consistent with baselines and approved changes.

Types of Audits:

1. Physical Configuration Audit (PCA):

   • Verify that all items are present and complete.
   • Example:

     “Ensure that release_v1.0 contains all required code files, SRS, and deployment scripts.”

2. Functional Configuration Audit (FCA):

   • Validate that the system meets the documented requirements.
   • Example:

     “Confirm that task_manager.py in v1.0 satisfies all task creation requirements from the SRS.”

Process:

• Use tools like Jenkins or GitHub Actions for build verification.
• Checklist Example:

  Item	Status
  Code files	Verified
  Test cases	Verified
  Documentation	Verified

6. Roles and Responsibilities

Key Roles:

1. Configuration Manager:

   • Oversees CM activities.
   • Ensures processes are followed.

2. Developers:

   • Follow branching, merging, and CI/CD rules.
   • Log changes accurately.

3. Auditors:

   • Conduct configuration audits.

Example Responsibility Matrix (RACI):

7. Backup and Recovery

Purpose:

• Ensure data integrity during development and deployment.

Backup Plan:

1. Daily backups of all repositories using AWS S3 or equivalent.
2. Retain 7 daily backups and 4 weekly backups.
3. Example:

   “Database backups stored in s3://backups/project-db-daily. Latest backup: 2024-01-15.sql.”

Recovery Plan:

1. Identify the last stable baseline.
2. Pull the baseline from version control.
   • Example:

     “To recover from a failed deployment, pull release_v1.0 tag and redeploy.”

8. Tools

• Version Control: Git/GitHub.
• Issue Tracking: Jira, Trello.
• CI/CD: Jenkins, GitHub Actions.
• Audit Support: SonarQube (for static code analysis).

Examples

1. Baseline:
   • “Baseline v2.0 includes APIs for user authentication and task management, with 100% test coverage.”
2. Change Request Log:

   ID: CR-456
   Description: Update login password policy to require 12 characters.
   Impact: Affects backend APIs and UI validations.
   Status: Approved.
   

Comprehensive Sheet for SPMP (Software Project Management Plan)

The Software Project Management Plan (SPMP) is a critical document that outlines how the project will be planned, executed, monitored, and controlled. This breakdown provides all sections with detailed explanations, practical examples, and templates to help you create an SPMP in any scenario.

1. Introduction

Purpose:

• Describe the goals and scope of the project.
• Provide an overview of what the project will deliver and why.

Key Elements:

1. Project Objectives:

   • Example:

     “Develop a task management web application for teams to assign, track, and complete tasks efficiently.”

2. Scope:

   • Clearly define project boundaries.
   • Example:

     “The system will allow task assignment, tracking progress, and generating reports but will not include real-time chat functionality.”

3. Stakeholders:

   • Identify key stakeholders (e.g., customers, end users, development team).
   • Example Table:

     Stakeholder	Role	Interest
     Product Owner	Defines requirements	Ensure timely delivery
     Development Team	Builds the product	Ensure clarity of requirements

2. Team Organization

Purpose:

• Define the roles and responsibilities of the team.

Key Elements:

1. Team Structure:

   • Example Roles:
     • Project Manager (PM): Coordinates tasks, schedules, and risks.
     • Developers: Implement features, resolve bugs.
     • QA Team: Conducts testing.
     • UI/UX Designers: Create user interfaces and workflows.

2. RACI Matrix:

   • Example:

     Task	Responsible	Accountable	Consulted	Informed
     Create UI Wireframes	UI Designer	PM	Developers	QA Team
     Develop Login API	Backend Dev	Tech Lead	QA Team	PM

3. Project Phases

Purpose:

• Outline the phases of the project and associated milestones.

Key Elements:

1. Phases and Milestones:

   • Example Table:

     Phase	Duration	Milestone
     Requirements Gathering	2 weeks	Finalized SRS
     Design	3 weeks	Approved SDD
     Development	6 weeks	Feature-complete MVP
     Testing	2 weeks	100% Test Coverage
     Deployment	1 week	Live Production

2. Deliverables:

   • Clearly list expected outputs for each phase.
   • Example:
     • Phase 1 Deliverable: SRS document.

4. Scheduling

Purpose:

• Define timelines and dependencies for tasks.

Key Elements:

1. Gantt Chart:

   • Use tools like Excel or Jira to visualize timelines.
   • Example:

     Week 1-2: Gather Requirements
     Week 3: Create UI Wireframes
     Week 4-6: Develop Backend Features
     

2. Critical Path:

   • Highlight dependencies to identify the sequence of critical tasks.
   • Example:

     “Backend APIs for login must be completed before UI testing can begin.”

5. Resource Allocation

Purpose:

• Specify the human, technical, and financial resources required for the project.

Key Elements:

1. Human Resources:

   • Example Table:

     Role	Name	Availability
     PM	Jane Doe	20 hrs/week
     Frontend Dev	John Smith	Full-time

2. Technical Resources:

   • Tools, hardware, and environments needed.
   • Example:
     • Laptops: 5 MacBooks for developers.
     • Tools: VS Code, Docker, Jenkins.

3. Budget:

   • Example:
     • Developer Salaries: $40,000.
     • Tools & Hosting: $5,000.

6. Risk Management

Purpose:

• Identify, prioritize, and mitigate project risks.

Key Elements:

1. Risk Identification:

   • Example:

     Risk	Description
     Scope Creep	Uncontrolled changes to requirements.
     Resource Unavailability	Key personnel unavailable during critical phases.

2. Risk Analysis:

   • Evaluate likelihood and impact on the project.
   • Example Table:

     Risk	Likelihood (1-10)	Impact (1-10)	Priority (H/M/L)
     Scope Creep	7	8	High

3. Mitigation Strategies:

   • Example:

     “Scope creep will be mitigated by freezing requirements after the SRS is approved.”

7. Project Monitoring and Control

Purpose:

• Track progress and ensure the project stays on schedule and within budget.

Key Elements:

1. Performance Metrics:

   • Example:
     • Task Completion Rate: 80% of tasks completed on schedule.
     • Budget Utilization: Stay within 10% of budget.

2. Tracking Tools:

   • Use Jira/Trello for task management.
   • CI/CD pipelines (Jenkins) for monitoring builds and deployments.

3. Communication Plan:

   • Example:

     Channel	Frequency	Purpose
     Daily Stand-ups	Daily (15 mins)	Discuss progress/blockers
     Sprint Review Meetings	Bi-weekly	Demonstrate completed features

8. Estimation

Purpose:

• Provide realistic estimates for time, cost, and effort.

Key Elements:

1. Effort Estimation:

   • Use LOC (Lines of Code) or Function Point Analysis.
   • Example:

     “The login module is estimated to require 1,000 LOC, taking 40 developer hours.”

2. Cost Estimation:

   • Break down costs into development, testing, and deployment.
   • Example Table:

     Cost Category	Amount
     Developer Salaries	$40,000
     Hosting & Tools	$5,000

3. Schedule Estimation:

   • Example:

     “The project is estimated to take 12 weeks, with a 10% buffer for delays.”

9. Communication Plan

Purpose:

• Define how the team and stakeholders will communicate.

Key Elements:

1. Communication Matrix:

   • Example:

     Audience	Purpose	Frequency	Medium
     Development Team	Task Updates	Daily	Slack, Stand-ups
     Stakeholders	Progress Reports	Bi-weekly	Zoom, Email

2. Status Reporting:

   • Reports to stakeholders on progress, risks, and deliverables.
   • Example:

     “Weekly status reports will include a summary of completed milestones, pending tasks, and risks.”

Examples for SPMP

1. Project Scope:

   “The system will support task creation, assignment, progress tracking, and reporting. Features such as real-time chat and third-party integrations are out of scope.”

2. Risk Mitigation Example:

   “For resource unavailability, a secondary backend developer will be trained to act as a backup.”

3. Schedule Example:

   Week 1-2: Gather requirements.
   Week 3: Create UI wireframes.
   Week 4-6: Develop backend features.
   Week 7-8: Integration and testing.
   

Comprehensive Sheet for SRS (Software Requirements Specification)

The Software Requirements Specification (SRS) is a detailed document outlining the functional and non-functional requirements of a software system. It serves as a contract between stakeholders and the development team to ensure clarity and alignment on what the software must do.

1. Purpose

• Define goals and scope of the system.
• Establish the intended functionality, constraints, and external interfaces.
• Serve as a reference for developers, testers, and stakeholders.

Example:

“The purpose of this SRS is to define the functional and non-functional requirements for the Task Management System, enabling users to create, assign, and track tasks.”

2. Key Sections

1. Introduction

• Purpose: Why the system is being built.
• Scope: High-level overview of the system’s functions and boundaries.
• Audience: Who the SRS is intended for (e.g., developers, testers, stakeholders).
• Definitions and Acronyms: Define terms used frequently in the document.

Example:

• Scope:

  “The system will allow users to create tasks, assign them to team members, track progress, and generate completion reports.”

• Acronyms:

  UI – User Interface; API – Application Programming Interface.

2. Overall Description

1. System Overview:

   • Brief description of the system’s functionality.
   • Example:

     “The Task Management System will allow users to manage team tasks, set deadlines, and track progress through a web-based interface.”

2. System Context:

   • Context diagram showing the system’s interaction with external systems or users.
   • Example Diagram:

     [User]  [Task Management System]  [Database]
     

3. Assumptions and Constraints:

   • Example:
     • Assumption: “All users will have access to the internet.”
     • Constraint: “The system must run on Chrome, Firefox, and Safari browsers.”

3. Functional Requirements

Functional requirements define the specific actions and behaviors of the system.

Key Elements:

1. Requirement ID and Description:

   • Example Table:

     ID	Description	Priority
     FR1	The system shall allow users to create tasks.	High
     FR2	The system shall allow users to assign tasks to team members.	High
     FR3	Users shall receive notifications when a task is due.	Medium

2. Use Cases:

   • Describes user interactions with the system.
   • Example:
     • Use Case Name: Create Task.
     • Actors: User.
     • Steps:
       1. User logs into the system.
       2. User clicks “Create Task.”
       3. User enters task title, description, and due date.
       4. System saves the task and confirms creation.

4. Non-Functional Requirements

Non-functional requirements specify the quality attributes of the system.

Categories:

1. Performance:

   • Example:

     “The system shall handle 100 concurrent users with a response time of

2. Reliability:

   • Example:

     “The system shall have an uptime of 99.9%.”

3. Security:

   • Example:

     “Passwords must be encrypted using SHA-256.”

4. Usability:

   • Example:

     “The system must have a user-friendly interface with a maximum of 3 clicks required for any operation.”

5. Scalability:

   • Example:

     “The system must be scalable to support 1,000 users within 6 months.”

5. External Interfaces

1. User Interfaces (UI):

   • Include wireframes or descriptions of screens.
   • Example:
     • “The login page will include fields for username, password, and a ‘Forgot Password’ link.”

2. Hardware Interfaces:

   • Specify any hardware constraints.
   • Example:

     “The system must run on devices with at least 2GB of RAM.”

3. Software Interfaces:

   • Describe interactions with other software.
   • Example:

     “The system will use REST APIs to interact with the payment gateway.”

4. Communication Interfaces:

   • Define protocols for data exchange.
   • Example:

     “The system will use HTTPS for all data communication.”

6. Use Case Diagrams

Provide visual representations of interactions between users and the system.

Example:

Diagram for “Manage Tasks”:

[User] --> (Create Task)
[User] --> (Assign Task)
[User] --> (Generate Report)

7. Data Requirements

1. Database Design:

   • Example:

     CREATE TABLE Tasks (
       TaskID INT PRIMARY KEY,
       Title VARCHAR(255),
       DueDate DATE,
       AssignedTo INT FOREIGN KEY REFERENCES Users(UserID)
     );
     

2. Data Validation:

   • Example:

     “Task titles must be between 3 and 255 characters.”

3. Data Flow:

   • Example Diagram:

     [Frontend Form] --> [API] --> [Database]
     

8. Assumptions and Dependencies

• Identify external factors that the system depends on.
• Example:
  • Dependency: “System depends on a third-party email service for notifications.”
  • Assumption: “Users will provide valid email addresses during registration.”

Additional Sections

1. Appendices

Include any supplementary information, such as:

• Glossary of terms.
• References to related documents.

2. Index

Provide a quick way to locate specific sections.

Examples for Practical Application

Scenario: Task Management System

Functional Requirement Example:

“The system shall allow users to set task priorities (e.g., High, Medium, Low).”

Non-Functional Requirement Example:

“The system shall respond to user actions within 1 second for 95% of operations.”

Use Case Example:

Title: Assign Task
Actors: Team Member
Steps:

1. User selects a task from the task list.
2. User clicks “Assign Task.”
3. System displays team members.
4. User selects a team member.
5. System assigns the task and sends a notification.

Tips for Writing an SRS

1. Use Clear Language:

   • Avoid ambiguity. Use phrases like “shall” for mandatory requirements.

2. Prioritize Requirements:

   • Mark requirements as High, Medium, or Low priority.

3. Include Visual Aids:

   • Use diagrams for clarity (e.g., UML, data flow diagrams).

4. Iterate:

   • Continuously refine the SRS as requirements evolve.

Comprehensive Cheat Sheet for SDD (Software Design Document)

The Software Design Document (SDD) outlines the architecture, components, data structures, and interfaces of the system. It serves as a bridge between the requirements (SRS) and the actual implementation, ensuring that developers, testers, and stakeholders have a clear understanding of how the system will be built.

1. Purpose

• Translate requirements (SRS) into a technical design blueprint.
• Provide detailed guidance for developers and testers.
• Ensure the system meets functional and non-functional requirements.

2. Key Sections

1. Introduction

• Purpose: Define the goals of the SDD and its relationship to other documents (e.g., SRS).
• Scope: Outline the system’s key design features.
• References: Link to related documents like the SRS, SPMP, and SCMP.

Example:

“This SDD describes the design for the Task Management System, covering its modular architecture, data design, and interface specifications.”

2. System Overview

• Architecture Style: Define the architectural approach.
  • Examples:
    • Monolithic: Single application with integrated components.
    • Microservices: Independent services communicating via REST APIs.

Example:

“The Task Management System uses a microservices architecture to enable scalability and modularity.”

3. System Architecture

1. High-Level Design:

   • Overview of major components and their interactions.
   • Example:
     • Components: UI, API Gateway, Backend Services, Database.
     • Diagram:

       [User Interface]  [API Gateway]  [Task Service]
                                             [Notification Service]
                                             [Database]
       

2. Component Responsibilities:

   • Example:

     Component	Responsibilities
     UI	Display tasks, collect input.
     API Gateway	Route requests to appropriate backend services.
     Task Service	Handle task creation, updates, and deletions.

4. Detailed Design

• Provides low-level details about components, classes, and interactions.

1. Class Diagrams:

   • Show relationships between classes.
   • Example:

     Class: Task
     - Attributes:
       * taskId: int
       * title: string
       * dueDate: Date
       * assignedTo: int
     - Methods:
       * createTask()
       * deleteTask()
       * assignTask()
     

1. Sequence Diagrams:

   • Describe interactions over time for key operations.
   • Example: “User creates a task.”

     [User] --> [UI]: Click 'Create Task'
     [UI] --> [API Gateway]: POST /tasks
     [API Gateway] --> [Task Service]: Create task
     [Task Service] --> [Database]: Insert task
     [Task Service] --> [API Gateway]: Return success
     [API Gateway] --> [UI]: Display success message
     

2. State Diagrams:

   • Show possible states of an object and transitions.
   • Example: Task State Transitions

     [Pending] --> (Assigned) --> [In Progress] --> (Completed)
                                   \--> (Cancelled)
     

3. Data Flow Diagrams (DFD):

   • Show how data moves between components.
   • Example:

     [User Input] --> [Frontend Form] --> [API] --> [Database]
     

5. Data Design

1. Database Schema:

   • Define tables, attributes, relationships, and constraints.
   • Example:

     CREATE TABLE Tasks (
       taskId INT PRIMARY KEY,
       title VARCHAR(255) NOT NULL,
       dueDate DATE,
       assignedTo INT,
       FOREIGN KEY (assignedTo) REFERENCES Users(userId)
     );
     

2. Data Storage:

   • Describe how data will be stored and retrieved.
   • Example:

     “All task data will be stored in a PostgreSQL database, while logs are stored in AWS S3.”

3. Indexes:

   • Optimize query performance.
   • Example:

     “An index will be created on the dueDate field for faster query performance.”

6. Interface Design

1. User Interface (UI):

   • Describe UI wireframes or interactions.
   • Example:
     • Screen: “Task Dashboard”
     • Features:
       • List of tasks with filters (e.g., status, priority).
       • Buttons: “Add Task,” “Edit Task,” “Delete Task.”

2. API Design:

   • Define API endpoints, input/output, and error handling.
   • Example:

     Endpoint	Method	Description	Request/Response
     /tasks	POST	Create a new task	{ "title": "Buy Milk" } → 201 OK
     /tasks/:id	GET	Retrieve task details	200 OK → { "taskId": 1, ... }
     /tasks/:id	DELETE	Delete a task	204 No Content

7. Design Patterns

1. Pattern Selection:

   • List patterns used and justify their choice.
   • Examples:
     • Singleton:
       • Use for shared resources (e.g., logging service).
     • Observer:
       • Notify UI components when a task changes state.
     • Factory:
       • Encapsulate object creation.

2. Implementation Example:

   • Singleton Logging Service:

     class Logger:
         _instance = None
     
         @staticmethod
         def getInstance():
             if Logger._instance is None:
                 Logger._instance = Logger()
             return Logger._instance
     
         def log(self, message):
             print(message)
     

8. Non-Functional Design

Address system constraints and quality attributes.

1. Performance:

   • Example:

     “The system must handle 200 concurrent API calls with a response time of

2. Scalability:

   • Example:

     “The microservices architecture ensures horizontal scalability for up to 10,000 users.”

3. Security:

   • Example:

     “Use OAuth 2.0 for authentication and HTTPS for all communication.”

9. Assumptions and Dependencies

• Highlight external factors or conditions required for the design.
• Example:
  • Assumption: “Users will have modern browsers (Chrome, Firefox).”
  • Dependency: “The system depends on an external email notification service.”

10. Glossary

Provide definitions for technical terms, abbreviations, and acronyms.

• Example:
  • CRUD: Create, Read, Update, Delete.
  • REST: Representational State Transfer.

Examples for Practical Application

Scenario: Task Management System

1. High-Level Design:

   [Frontend]  [API Gateway]  [Task Service]  [Database]
   

2. API Example:

   • POST /tasks:
     • Request: { "title": "Write report", "dueDate": "2024-01-10" }
     • Response: { "taskId": 1, "status": "success" }

3. State Diagram:

   [Pending] --> [In Progress] --> [Completed]
               \--> [Cancelled]
   

Tips for Writing an SDD

1. Use Visual Aids:

   • Include diagrams for architecture, class design, and workflows.

2. Align with SRS:

   • Ensure all functional requirements in the SRS are addressed in the SDD.

3. Focus on Clarity:

   • Use tables and bullet points for readability.

4. Iterate:

   • Update the SDD as new requirements or design changes emerge.

CS 673 Lab 2

1. Give an example of a software application in which the customer, who pays for the work, is the same as the end user. Give an example in which they are different. In each case, identify the customer and the end user.

Ans:

1.1) 

An example where the customer who pays for the software is the end user:

A person who wants to play video games. 

Customer: A person who is interested in playing video games

End-user:  The same person who is interested in playing video games

Explanation: In this situation, both the customer and the end user are the same, the customer pays for the video game themselves and the customer is the end user for the product. Both the sale agreement and the usage agreement happen between only two parties. 

1.2)

An example where the customer who pays for the software is not the same as the end user of that software:

A university buying Windows Operating System licenses for their devices across the schools.

Customer: The customer here is the IT department of the university which buys the software licenses from Microsoft. 

End-user: Any person who is using the Windows system at the university.
Explanation: In this situation, both the customer who pays for the software and the end-user are different, which is a more complicated situation compared to the earlier example. In this situation, a sales agreement happens between the IT Department and the company selling the software, however, a usage agreement and service happen between the end user and the company. The level of service provided for the customer and the end user is determined by the customer and the company before the licenses are bought, usually, the end user does not have say regarding those agreements. 

2. Agile requirements gathering calls for a customer representative to work continually with the development team while generating requirements. Describe a scenario in which this type of arrangement may not work well and may result in poor requirements.

Ans:

2.1) 

Industries with strict regulations:

Industries such as aviation, healthcare, law, etc., require strict adherence to compliance laws. The agile method of requirement analysis may not work well as during the development phase, a lot of changes might happen and the developers may have to go back and forth to check for compliance. For these industries, it is necessary to gather compliance-related requirements for the project beforehand and propose alternatives to the client. That is why the iterative approach of agile may not work for these industries. 

2.2)

Customers with limited availability:

The agile method requires the customer to be in touch with the development team for all subsequent iterations after the project development begins. If the customer is unavailable, the development team may have to rely on assumptions and the customer may not approve the end product. 

2.3)

Large companies with complex corporate structures:

The agile methodology may not be suitable for large companies as they usually tend to have complex hierarchal structures, which would require navigating between different teams to get requirements from different customers, which would be difficult to coordinate to gather right requirements. 

3. Describe in your own words the dIfference between customer wants and customer needs. Provide an example that illustrates the difference. Explain why a mismatch between the two might cause problems.

Ans:

3.1) 

Customer wants: This might include to nice to have features which are not the core functionality for the application. These features may get prioritized by the customer which might lead to delay to achieving the core functionality of the application. 

Example: The customer may want social media sharing options or messaging capabilities in an application, however they would not serve the primary functionality of the application. 

Customer needs: The customer needs are the must have features in a software application which are to be prioritized to get the application up and running and serve its primary purpose. These features may include ability to authenticate users and functioning API calls in the backend, the database and the data schema is well designed to serve all kinds of requests and traffic to the application. 

Example: In banking applicaiont, the customer needs would be able to authenticate users and transactions, and the ability to send and receive money.

3.2) 

Mismatch of customer needs and wants:

If the developers focus on the developing on the “customer wants” features and if the those features are being hindered by any unexpected delays, the entire application’s core functionality implementation might get delayed, resulting in overal delay for the project completion. Therefore, there has to be plan in place to priotize the features to be implemented in any software project based on the customer wants and customer needs, so the developers focus on the getting the core functionality working first. In case of unexpected delays, the customer would still have an application capable of performing the core functionality. 

Example: In a banking application, if social media features are priotized instead of core banking features, that app might get delayed if the nice-to-have features hold back the development of core banking functionality.

4. Consider an application that manages patients in a doctor’s office. Patients call for an appointment and their information is entered into the application. Patients can call to reschedule or cancel appointments. After a patient is seen by a doctor, the patient may be referred to another doctor for treatment if necessary. Write three (3) high-level functional requirements for this application and an associated user story for each.

Ans:

Requirement 1: The ability to book, cancel, and reschedule appointments as a patient.

User story: As a patient, I want to book, cancel, or reschedule my doctor’s appointment with ease so I can manage my off-work availability effectively.

Requirement 2: The ability to update patient records after each visit as a doctor. 

User story: As a doctor, I want to be able to document a patient’s medical history and track progress over each visit by the patient. 

Requirement 3: The ability to refer to other doctors. 

User story: As a doctor, if I come across any additional test or consultation that is needed by the patient from a specialist, then I would want to refer to other doctors for further investigation or treatment. 

5. Write three (3) high-level non-functional requirements for a facial recognition application for security cameras that will be installed near the turnstiles at subway stations. 

Ans:

Non functional requirements:

Requirement 1: Performance 

The application must be able to process the facial recognition really fast, as the application might be used in high traffic areas, where a person might be visible for less than few seconds, so it would be important to prioritize the performance of the operation. The application should be able to identify the faces in real time ideally. 

Requirement 2: Accuracy

The application should ensure the accuracy of the identification of the faces. The system might be used by law enforcement and for other legal cases, developers must prioritize to detect false flags and develop robust system for identification. 

Requirement 3: Scalability 

The application must be equipped with good computing power to ensure fast performance in case there is increase of subway stations or the cameras at the stations. The developers should make sure to paralellize all the process to scale the system better. The scalability also becomes a factor during peak powers in the morning and evening, so the developers should ensure the system performs as expected during rush hour. 

Feedback to Learner10/18/24 10:45 AM

Quiz 1

1. Class Inheritance

Question: Which of the following classes inherit from which?

2. Class Inheritance

Question: Which one of the classes listed below is the best candidate for being the parent (base) class of the child (derived) class Mouse?

Correct Answer: InputDevice

3. Fill in the Blanks

Question: A/an [A] process is typified by repeated execution of the waterfall phases, in whole or in part, resulting in a refinement of the requirements, design, and implementation. Such a process is [B] if each iteration is relatively small. At the conclusion of such a process, a piece of operational code is produced that supports a subset of the final product functionality and features.

4. Fill in the Blanks

Question: _____ _____ _____ is a process for managing all the artifacts produced on a software project, including source code, specifications, and supporting software. For example, it ensures that the proper source files are included when building the software system and that the correct project documentation is retrieved when required.

Correct Answer: Software Configuration Management

5. Fill in the Blank

Question: A software _____ is a framework for carrying out the activities of a project in an organized and disciplined manner. It imposes structure and helps guide the many people and activities in a coherent manner.

Correct Answer: process

6. Agile Manifesto

Question: Which one of the items below is not one of the values of the Agile Manifesto?

Correct Answer: Iterative development over Waterfall process

7. Matching Terms

Question: Match the following terms that are often used synonymously.

8. COCOMO (I) Model

Question: Which of the three variables below are included in the COCOMO (I) project estimation model equations for estimating the potential duration of a project?

Correct Answers:

• KLoC (number of thousands of lines of code)
• Effort
• Duration

9. UML State Diagrams

Question: Which triplet of concepts listed below is used in a State Diagram that describes the relationships between them?

Correct Answer: State, event, transition

10. Nonfunctional Requirements

Question: Which one of the statements below is a good example of a nonfunctional requirement?

Correct Answer: Upon completing the account setup, the system shall send a confirmation email to the user within 2 minutes.

11. Git Branching

Question: Which Git command is used to switch between branches?

Correct Answer: git checkout

12. The Four P’s of Software Engineering

Question: Select the four P’s that constitute the major concerns and activities of software engineering.

Correct Answers:

• People
• Process
• Product
• Project

13. UML – Aggregation

Question: Which pair of (whole and part) classes listed below is more likely to be associated as an aggregation in a UML class diagram?

Correct Answer: Classroom and Student

14. Software Development Lifecycle

Question: Which list below shows the main phases of a software project in the correct traditional order?

Correct Answer: Planning, requirements analysis, design, implementation, testing, maintenance

Quiz 2

1. REST APIs and CRUD Operations

Question: Match the typical REST API methods with corresponding CRUD operations.

2. MVC Design Pattern

Question: In the MVC design pattern, the [A] handles the user input, the [B] represents the data or the business logic, and the [C] is responsible for displaying the data to the user.

3. Software Architecture Design

Question: In software architecture design, the ______ architecture uses small, modular, and self-contained services that communicate over typically lightweight protocols between the server and the clients.

Correct Answer: Microservices

4. CRUD for API Design

Question: What does the acronym CRUD stand for in API design?

Correct Answer: Create, Read, Update, Delete

5. Design Patterns

Question: Which one of the items below is NOT one of the traditional software design patterns?

Correct Answer: Context

6. Types of Software Design (or UML) Diagrams

Question: Match the following definitions to the correct UML diagram type.

7. UML Design – Relationships

Question: In object-oriented or UML design, ______ describes a relationship between classes in which one class assumes the attributes and operations of another. This relationship is often thought of as an “is-a” relationship.

Correct Answer: Inheritance

8. Goals of UX Design

Question: Which one of the following items is the main objective of UX design?

Correct Answer: To ensure smooth user interactions with the product

9. Preconditions for Functionality

Question: Which items below are possible preconditions for a function for withdrawing money from a checking account at an ATM?

Correct Answers:

• The sum being withdrawn should be smaller than the sum of money available in the ATM machine.
• The sum being withdrawn should be smaller than or equal to the current sum on the checking account.

10. Real-Time Communication Protocol

Question: Which internet protocol is designed specifically for real-time communication between a server and web clients?

Correct Answer: WebSocket

11. UML Associations

Question: A/An [A] is a type of association that can be thought of as a whole-part relationship. It indicates the structural inclusion of objects of one class by another. A/An [B] is a stronger form of this association in which the included objects exist only during the lifetime of the including object.

12. UI vs UX

Question: User interface (UI) design includes user experience (UX) design as a subset, while including additional design concerns such as the look-and-feel of the product.

Correct Answer: False

13. RESTful API and HTTP Methods

Question: In web applications, RESTful APIs use standard HTTP methods such as [A] for reading data, [B] for creating data, and [C] for updating data.

14. Microservices Architecture

Question: Which one of the following is NOT a benefit of using microservices architecture?

Correct Answer: Tight coupling

15. Focus Areas of UX Design

Question: What are the main areas of focus of user experience design? (Choose only four items)

Correct Answers:

• Accessibility
• Usability
• Performance
• Aesthetics

Quiz 3

1. HTML Accessibility

Question: What is the primary accessibility issue with the following HTML image tag?

Correct Answer: It is missing an alt attribute.

2. Keyboard Accessibility

Question: Which of these is crucial for making interactive elements accessible to keyboard users?

Correct Answer: Keyboard focusability.

3. WCAG Acronym

Question: What does the acronym “WCAG” stand for in web development?

Correct Answer: Web Content Accessibility Guidelines.

4. Semantic HTML

Question: What is the purpose of semantic HTML in web accessibility?

Correct Answer: To define the structure and meaning of web content.

5. Color Use in UI

Question: True or False:
If the UI design calls for it, it is acceptable to use color alone as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Correct Answer: False.

6. Accessibility Features

Question: Which of the following is NOT a common feature of accessible software?

Correct Answer: Captcha for user authentication.

7. ARIA Acronym

Question: What does “ARIA” stand for in web development?

Correct Answer: Accessible Rich Internet Applications.

8. Motor Impairments

Question: Fill in the Blank:
To ensure accessibility for users with motor impairments, software applications should be designed to be fully navigable using a/an ______.

Correct Answer: Keyboard.

9. Screen Reader Accessibility

Question: Which HTML attribute is crucial for making images accessible to screen readers?

Correct Answer: alt.

10. Accessible HTML Buttons

Question: Why would the following custom HTML “button” design not be considered accessible to screen reader users?

[User] → [API] → [Database]

if (isHit && hasShield) {
    dropShield();
}

def getClientBySSN(ssn):
    # Retrieves account details based on SSN

def test_add_numbers():
    result = add(2, 3)
    assert result == 5, "Expected 5 but got {}".format(result)

Total Statements: 90%
Total Branches: 85%

def test_add():
    assert Calculator.add(2, 3) == 5

class Calculator:
    @staticmethod
    def add(a, b):
        return a + b

def binary_search(arr, target):
    left, right = 0, len(arr) - 1
    while left