🚀 CST309 – MANAGEMENT OF SOFTWARE SYSTEMS 🔥

1. Waterfall model
2. Incremental development model
3. Integration and configuration (Reuse-oriented) model

Attribute	Description
Maintainability	Software must evolve to meet changing customer needs
Dependability & Security	Reliable, safe, secure; should not cause damage on failure
Efficiency	Should not waste resources (memory, processor cycles)
Acceptability	Understandable, usable, and compatible with other systems

1. Facilitates early design decisions affecting quality attributes
2. Enables communication among stakeholders
3. Supports system analysis, reuse, and large-scale development

1. Requirements elicitation and analysis
2. Requirements specification
3. Requirements validation
4. Requirements management

Post-mortem evaluation is a review conducted after project completion to analyze successes, failures, root causes, and lessons learned. It helps improve future processes by documenting best practices and avoiding repeated mistakes.

Criteria	White Box Testing	Black Box Testing
Knowledge Required	Full internal code structure	No knowledge of internal code
Focus	Logic, paths, code coverage	Functionality and behavior
Performed By	Developers	Testers / Users

1. Algorithmic Cost Modeling (COCOMO): Uses mathematical equations based on size, complexity, and effort multipliers.
2. Expert Judgment: Experienced professionals estimate based on analogy with past projects.

1. Version identification and tracking
2. Branching and merging of code
3. Build and release management with rollback

1. Transient failure: Temporary (e.g., network timeout)
2. Cascading failure: One service failure affects others
3. Permanent failure: Service crashes and needs restart

The six characteristics are:
1. Functionality
2. Reliability
3. Usability
4. Efficiency
5. Maintainability
6. Portability

1. Functionality and compatibility
2. Performance and reliability
3. Cost, licensing, and vendor support
4. Scalability and future maintainability

Agile uses iterative development, user stories, frequent demos, and close customer collaboration. This allows continuous feedback and refinement of requirements instead of fixing them upfront, leading to better understanding and reduced misunderstanding.

Steps:
1. Elicit requirements via interviews, workshops
2. Analyze and prioritize them
3. Document in structured SRS (introduction, functional & non-functional requirements, constraints)
4. Validate with stakeholders and get approval

Criteria	Functional	Non-Functional
Definition	What the system should do	How well the system performs
Example	User login, generate report	Response time < 2 sec, 99.9% uptime
Verification	By testing features	By measuring performance, security, etc.

Criteria	GPL	LGPL
Linking with proprietary code	Not allowed	Allowed (for libraries)
Derivative works	Must be GPL	Can remain proprietary
Main Use	Full applications	Reusable libraries

1. Project planning: Define scope, schedule, resources
2. Risk management: Identify and mitigate risks
3. Monitoring & control: Track progress
4. People management: Team coordination and motivation

Product Backlog: Prioritized list of all features and tasks.
Sprint Backlog: Selected items for current sprint.
Sprint: 2–4 week time-box to deliver working increment.
→ Enables iterative delivery, continuous feedback, and adaptability.

1. On-demand self-service
2. Broad network access
3. Resource pooling and rapid elasticity
4. Measured service (pay-per-use)

Balancing high quality (reliability, performance) with time and cost constraints. Higher quality increases development effort and delay, but poor quality leads to high maintenance and failure costs later.

1. Early delivery of useful software
2. Easier to handle changing requirements
3. Reduced risk through continuous validation
4. Better customer feedback and involvement

Aspect	Plan-Driven	Agile
Planning	Upfront complete plan	Adaptive, iterative planning
Requirements	Fixed at start	Evolve continuously
Delivery	One final delivery	Frequent increments

1. Introduction (purpose, scope)
2. Overall description (product perspective, functions)
3. Specific requirements (functional, non-functional)
4. Supporting information (assumptions, appendices)

- Personas: Fictional characters representing user types
- Scenarios: Narrative descriptions of user interactions
- User Stories: Short requirements in format: "As a [user], I want [feature] so that [benefit]"
- Feature identification: Breaking system into valuable functionalities

1. Functional testing: Verifies features work as specified
2. Performance testing: Checks speed, scalability
3. Security testing: Identifies vulnerabilities
4. Usability testing: Evaluates user-friendliness

1. Corrective: Fixing defects
2. Adaptive: Adapting to new environment
3. Perfective: Adding features/improving performance
4. Preventive: Reducing future problems (refactoring)

Risk is the possibility of suffering loss.
Types:
1. Project risks: Affect schedule/resources (e.g., staff loss)
2. Product risks: Affect quality (e.g., poor usability)
3. Business risks: Affect organization (e.g., market change)

1. Development and maintenance cost
2. Market competition and demand
3. Perceived customer value
4. Licensing model and contractual terms

1. Standards and procedures
2. Reviews and audits
3. Testing and defect tracking
4. Process improvement and training

Level	Name	Description
1	Initial	Ad-hoc, chaotic processes
2	Managed	Projects planned and tracked
3	Defined	Standardized organization-wide processes
4	Quantitatively Managed	Measured and controlled
5	Optimizing	Continuous improvement

The Waterfall model consists of the following sequential phases:
1. Requirements analysis and definition – System services, constraints and goals are established through consultation with users and documented.
2. System and software design – Establishes overall system architecture; allocates requirements to hardware/software.
3. Implementation and unit testing – Software is written as program units; each unit is tested individually.
4. Integration and system testing – Units are integrated and tested as a complete system.
5. Operation and maintenance – Longest phase; system is installed, errors corrected, and enhancements made.

Situations where Waterfall is applicable:
• Embedded systems interfacing with inflexible hardware
• Critical/safety-critical systems requiring extensive analysis of specification and design
• Large systems developed by multiple partner companies needing formal documents

The Agile Manifesto defines 12 principles:
1. Highest priority is customer satisfaction through early and continuous delivery
2. Welcome changing requirements, even late in development
3. Deliver working software frequently (weeks rather than months)
4. Business people and developers must work together daily
5. Build projects around motivated individuals
6. Face-to-face conversation is the most efficient communication
7. Working software is the primary measure of progress
8. Promote sustainable development pace
9. Continuous attention to technical excellence and good design
10. Simplicity – maximizing work not done is essential
11. Best architectures emerge from self-organizing teams
12. Regular reflection and adjustment of behavior

Situations:
• Projects with high risk and unclear requirements
• Large, expensive, complicated projects
• Systems requiring frequent releases or prototypes
• Projects needing strong approval and documentation control

Advantages:
1. Strong risk analysis and management
2. Early user involvement through prototypes
3. Flexible – accommodates changes easily
4. Suitable for large and critical projects
5. Additional functionality can be added later
6. Produces working prototypes early
7. Better cost estimation at each spiral

Disadvantages:
1. Complex and requires risk assessment expertise
2. Time-consuming and costly
3. Not suitable for small projects
4. Success depends on risk analysis capability
5. End of project may not be known early

Four fundamental activities common to all software processes:
1. Software specification – Customers and engineers define the software to be produced and constraints on its operation.
2. Software development – The software is designed and programmed.
3. Software validation – The software is checked to ensure it meets customer requirements (testing, verification).
4. Software evolution – The software is modified to reflect changing customer and market requirements (maintenance).

Draw the Spiral Diagram:
• Four quadrants: 1. Determine objectives, 2. Identify and resolve risks, 3. Development and test, 4. Plan next iteration
• Each loop represents one phase
• Starts from center and spirals outward
• Risk level decreases as spirals progress
• Ends with final system delivery

Importance:
• Emphasizes risk analysis at each stage
• Allows prototyping and user feedback
• Combines advantages of waterfall and prototyping
• Ideal for large, complex, high-risk projects
• Supports iterative development with risk control

Differences:
• Traditional: Sequential phases, fixed requirements, documentation-heavy
• Agile: Iterative, incremental delivery, changing requirements welcome, working software over documentation

Case Study: COVID-19 Contact Tracing App (India – Aarogya Setu)
• Traditional approach would have taken 12–18 months with complete specification first
• Actual development used Agile: First version released in 11 days
• Daily updates based on government/health ministry feedback
• Features added incrementally: Bluetooth tracing, self-assessment, e-pass, vaccination status
• Over 200 million downloads due to rapid, adaptive development

1. Requirements change frequently → Incremental allows adaptation
2. Early delivery of core functionality
3. Immediate user feedback improves quality
4. Lower risk – problems detected early
5. Working software from first increment
6. Better customer satisfaction
7. Easier to test and debug small increments
8. Market can be captured faster
9. Revenue generation starts early
10. Can respond to competitor features quickly
11. Waterfall fails when requirements are unclear initially
12. 80% features used by 20% users → deliver core first
13. Technology changes rapidly → incremental allows integration
14. Most successful apps (Amazon, Flipkart, Instagram) use incremental approach

Pair Programming:
1. Two developers work together at one workstation
2. Improves code quality and reduces defects
3. Knowledge sharing within team
4. Immediate code review
5. Fewer integration issues

Refactoring:
1. Improving internal code structure without changing external behavior
2. Removes code smells and duplication
3. Makes code more maintainable
4. Supported by automated tests
5. Essential for sustainable pace
6. Keeps technical debt low

Refer to the respective questions above – exact same answers are repeated in the university question bank.

Functional requirements describe what the system should do. They state the fundamental actions the system must perform.

Examples:
• The system shall provide appropriate viewers for the user to read documents.
• Each order shall be allocated a unique identifier which the user shall use for tracking.

Non-functional requirements are constraints on the services or functions offered by the system (quality attributes).

Examples:
• Response time should be no more than 1 second for 95% of requests.
• The system shall support at least 500 concurrent users.
• The system shall run on both Windows and Linux platforms.
• Passwords must be encrypted using AES algorithm.

A software component is a modular unit of functionality with well-defined interfaces that can be independently deployed and composed.

Steps for designing class-based components:
1. Identify the classes from requirements and domain model.
2. Define the responsibilities of each class.
3. Specify the interfaces (public methods) that the class provides.
4. Hide internal data representation and implementation details (information hiding).
5. Define relationships between classes – inheritance, association, aggregation.
6. Ensure high cohesion and low coupling.
7. Use UML class diagrams to document the design.

1. Requirements discovery – Interviews, surveys, observation, workshops
2. Classification and organization – Grouping similar requirements, removing duplicates
3. Prioritization and negotiation – Resolving conflicts, deciding importance
4. Requirements documentation – Writing clearly and structured
5. Requirements validation – Checking with stakeholders for correctness

A persona is a fictional character created to represent a particular type of user.

Aspects of a persona:
• Name and photograph
• Demographics (age, education, job)
• Goals and tasks the persona wants to achieve
• Environment in which the persona works
• A quote that sums up what matters most
• Level of expertise and attitude toward technology

1. Requirements elicitation and analysis
2. Requirements specification
3. Requirements validation
4. Requirements management (handling changes)

A use case is a description of how a user (actor) uses the system to accomplish a goal.

ATM Use Case Diagram:
Actor: Customer
Use cases:
• Withdraw Cash
• Deposit Funds
• Transfer Funds
• Check Balance
• Change PIN

<> relationship: “Validate PIN” is included in all transaction use cases
<> relationship: “Print Receipt” extends Withdraw Cash and Deposit Funds

1. Abstraction – Focus on essential characteristics
2. Architecture – High-level structure
3. Patterns – Reusable solutions
4. Modularity – Dividing into separate modules
5. Information hiding – Hide implementation details
6. Refinement – Step-by-step elaboration
7. Cohesion – Elements belong together
8. Coupling – Degree of interdependence
9. Separation of interface and implementation

1. Repository – Central data store
2. Client-server – Request/response over network
3. Layered – Organized in layers
4. Pipe and filter – Data flows through transformations
5. Model-View-Controller (MVC) – Separates data, UI, control
6. Blackboard – Multiple knowledge sources cooperate

Verification: "Are we building the product right?" (process-oriented)
Validation: "Are we building the right product?" (customer-oriented)

White Box Testing:
• Full knowledge of internal code & structure
• Tests logic, paths, code coverage
• Techniques: statement, branch, path coverage
• Done by developers (unit testing)

Black Box Testing:
• No knowledge of internal code
• Tests functionality against requirements
• Techniques: equivalence partitioning, boundary value analysis, use-case testing
• Done by independent testers

1. Expert Judgment (Delphi technique):
• Group of experts independently estimate
• Moderator collects, returns average & outliers
• Re-estimate until consensus
• Based on analogy with past projects

2. Algorithmic Cost Modeling (COCOMO):
• Uses mathematical formulas
• Basic: Effort = a × (KLOC)^b person-months
• Intermediate adds 15 effort multipliers (reliability, complexity, analyst capability, etc.)

Role: Controls changes, maintains traceability, ensures only authorized versions are used.

Main activities:
• Version control and identification
• Change control (request → impact analysis → approval → implementation)
• Configuration auditing
• Build management and release management
• Status reporting

1. Transient failures – Temporary (network timeout) → retry fixes
2. Cascading failures – One service fails → overloads others
3. Permanent failures – Service crashes completely → needs restart/redeploy
4. Slow response failures – Service responds very slowly → affects performance

1. Corrective – Fixing bugs after delivery
2. Adaptive – Changing software for new environment (OS, hardware)
3. Perfective – Adding new features, improving performance
4. Preventive – Refactoring, restructuring to reduce future problems

Risk = Possibility of suffering loss due to uncertainty.

Types:
1. Project risks – Affect schedule/resources (staff turnover, poor planning)
2. Product risks – Affect quality/performance (poor usability, unreliable)
3. Business risks – Affect organization (market change, competitor launches better product)

COCOMO (Constructive Cost Model) – Boehm
• Basic COCOMO: Effort = a × (KLOC)^b
Organic: a=2.4, b=1.05
Semi-detached: a=3.0, b=1.12
Embedded: a=3.6, b=1.20
• Intermediate COCOMO: Adds 15 effort multipliers
• Detailed COCOMO: Applies multipliers at subsystem level
Development time = c × (Effort)^d months

1. Project planning – Scope, effort estimation, scheduling, resources
2. Risk management – Identify, analyze, mitigate risks
3. Project monitoring & control – Track progress, take corrective actions
4. People management – Team selection, motivation, coordination

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need.
6. The most efficient and effective method of conveying information is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development pace.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Product Backlog: Ordered list of everything needed in the product (maintained by Product Owner).
Sprint Backlog: Selected items for the current sprint + plan to deliver the increment.
Sprint: 2–4 week time-box creating a potentially releasable increment.
Daily Scrum, Sprint Review, Sprint Retrospective → enables rapid feedback, continuous improvement, adaptability to change.

1. On-demand self-service – Provision resources without human interaction
2. Broad network access – Available over network using standard mechanisms
3. Resource pooling – Provider’s resources pooled for multiple consumers
4. Rapid elasticity – Resources can be scaled up/down rapidly
5. Measured service – Usage monitored and reported (pay-as-you-go)

Six characteristics:
1. Functionality
2. Reliability
3. Usability
4. Efficiency
5. Maintainability
6. Portability

1. Standards and procedures definition
2. Reviews and audits
3. Testing activities
4. Defect tracking and analysis
5. Process improvement
6. Training and documentation
7. Tools and metrics
8. Configuration management support

Level	Name	Description
1	Initial	Ad-hoc, chaotic. Success depends on individual effort.
2	Managed	Projects planned, monitored, controlled.
3	Defined	Organization-wide standardized processes.
4	Quantitatively Managed	Processes measured and controlled statistically.
5	Optimizing	Continuous improvement based on quantitative understanding.

1. Development and maintenance costs
2. Market opportunity and competition
3. Customer perceived value
4. Licensing model (per user, subscription, etc.)
5. Contractual terms and support services
6. Economic conditions
7. Size and complexity of the software

YOU NOW HAVE THE COMPLETE CST309 INTERACTIVE CRAMMER!
Part A + Module 1 + 2 + 3 + 4&5 → 100% COVERED 🔥

ALL THE BEST LEGEND! 💪🚀