Software Engineering

Software Engineering

Solution

Pocketly on Android

Solution

Solution

Solution

Solution

Solution

Solution

Solution

Solution

Solution

Solution

Pocketly on Android

Solution

Solution

Solution - E-commerce for Electronic Products

Solution

Solution

Solution

Solution

Pocketly on Android

1. Waterfall Model (Classic / Linear Sequential)

2. When to Prefer Spiral over Waterfall

Explanation

Why others incorrect:

Explanation

Explanation

Explanation

Explanation

Explanation

Explanation

Explanation

Explanation

1. Waterfall Model (Classic / Linear Sequential)

2. When to Prefer Spiral over Waterfall

Facilities for Scientific Calculator

DFD Level 0 (Context Diagram)

DFD Level 1 (Decomposition)

(i) Project Manager

(ii) Project Leader / Team Lead

(iii) System Analyst

(iv) Developer / Programmer

(i) DFDs

(ii) SRS (Outline, IEEE 830)

(iii) ER Diagram

(iv) Gantt Chart (6 months)

(v) Suitable Process Model

Black Box Boundary Value Analysis (BVA)

(i) Peak Manning & Peak Time

(ii) Manpower cost after 1 year 2 months (t=1.17t = 1.17t=1.17 years)

Risk Management Activities (Boehm / SEI)

Is Prioritization Possible? YES

Architectural Styles (Sommerville/Pressman) - with Diagrams

(ii) Manpower cost after 1 year 2 months ( $t = 1.17$ years)

2020 question paper

17 questions

Q1a. A characteristic of a software system that can lead to a system error is known as (i) human error or mistake (ii) system fault (iii) system error (iv) system failure20202m
Module 4: Software Testing
A characteristic of a software system that can lead to a system error is known as

(i) human error or mistake
(ii) system fault
(iii) system error
(iv) system failure

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (ii) system fault

Explanation

As per IEEE definitions (also Pressman/Sommerville):

Human Error / Mistake - Human action that produces an incorrect result

Fault / Defect / Bug - Characteristic / Anomaly in the software (e.g., wrong code, missing logic) that can lead to an error. It is a static condition.

Error - Human-observable incorrect internal state (failure may not yet have occurred)

Failure - Observable deviation from required behavior when system no longer performs required function

Chain: Mistake → Fault → Error → Failure

Hence a characteristic of the system that can lead to a system error is a Fault.

Why others incorrect:

(i) Human error is the cause of fault, not a characteristic of the system itself

(iii) Error is the result of fault, not the fault itself

(iv) Failure is the final observable consequence after error propagates

Answer: (ii) system fault
Q1b. Which of the following is a complementary approach to function-oriented approach? (i) Object-oriented analysis (ii) Object-oriented design (iii) Structured approach (iv) Both object-oriented analysis and design20202m
Module 3: Software Design & Metrics
Which of the following is a complementary approach to function-oriented approach?

(i) Object-oriented analysis
(ii) Object-oriented design
(iii) Structured approach
(iv) Both object-oriented analysis and design

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iv) Both object-oriented analysis and design

Explanation

Function-oriented approach = Focuses on functions/procedures and data flow (DFD, Structured Design).

Object-oriented approach is considered complementary to it because OO covers the entire lifecycle with objects:

OOA (Object Oriented Analysis) - complements function-oriented analysis by modelling objects, attributes and relationships instead of just processes.

OOD (Object Oriented Design) - complements function-oriented design by designing classes, inheritance, polymorphism, encapsulation.

In Pressman and standard SE literature, OOA and OOD together are stated as complementary to the function-oriented paradigm. Choosing only one is incomplete.

Answer: (iv) Both object-oriented analysis and design
Q1c. Which of the following is not a use of a CASE tool? (i) It supports structured analysis and design (SA/SD) (ii) It maintains the data dictionary (iii) It checks whether DFDs are balanced or not (iv) It complies with the available system20202m
Module 2: Requirements & SRS
Which of the following is not a use of a CASE tool?

(i) It supports structured analysis and design (SA/SD)
(ii) It maintains the data dictionary
(iii) It checks whether DFDs are balanced or not
(iv) It complies with the available system

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iv) It complies with the available system

Explanation

CASE (Computer-Aided Software Engineering) tools are used for:

(i) Supporting SA/SD - YES: Upper CASE tools support Structured Analysis & Design (DFD, ERD, UML)

(ii) Maintaining data dictionary - YES: Central repository / data dictionary is core CASE function

(iii) Checking DFD balance - YES: CASE tools do syntax/semantic checks e.g., balancing Level-0 and Level-1 DFDs, completeness checks

(iv) It complies/compiles with available system - NOT a use. CASE tools do not compile with system nor ensure compliance with hardware/OS. That is the job of compilers/compatibility tools. This option is irrelevant to CASE purpose.

Note: Variant phrasing "It compiles with the available system" (Q29 - 2022) is same answer - also (iv).

Answer: (iv) It complies with the available system
Q1e. Which of the following is not a part of bug report? (i) Test case (ii) Output (iii) Software version (iv) LOC20202m
Module 4: Software Testing
Which of the following is not a part of bug report?

(i) Test case
(ii) Output
(iii) Software version
(iv) LOC

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iv) LOC

Explanation

Standard Bug Report / Defect Report contains:

Test case (steps to reproduce) - (i) YES

Output / Actual result + Expected result + Screenshot - (ii) YES

Software version / Build, Environment, OS, Severity, Priority, Reporter - (iii) YES

LOC (Lines of Code) - NO. LOC is a project metric, not part of bug reporting. Defect report never asks for total LOC.

Some variations also list "Unexpected output" vs "LOC" - always LOC is the odd one out.

Answer: (iv) LOC
Q1f. Cyclomatic complexity method comes under which testing method? (i) Yellow box (ii) White box (iii) Grey box (iv) Black box20202m
Module 3: Software Design & Metrics
Cyclomatic complexity method comes under which testing method?

(i) Yellow box
(ii) White box
(iii) Grey box
(iv) Black box

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (ii) White box

Explanation

Cyclomatic Complexity $V(G) = E - N + 2P$ (McCabe, 1976) measures number of linearly independent paths.

It requires source code / control flow graph → hence White-box / Structural / Glass-box testing.

Used for basis path testing, to determine number of test cases.

Other categories:

Black box - without code knowledge (BVA, Equivalence Partitioning)

Grey box - partial knowledge

Yellow box is not a standard term (distractor).

Answer: (ii) White box (also called Glass box / Structural testing)
Q1g. In size-oriented metrics, metrics are developed based on the (i) number of functions (ii) number of user inputs (iii) number of lines of code (iv) amount of memory usage20202m
Module 3: Software Design & Metrics
In size-oriented metrics, metrics are developed based on the

(i) number of functions
(ii) number of user inputs
(iii) number of lines of code
(iv) amount of memory usage

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iii) number of lines of code

Explanation

Size-oriented metrics:

Developed based on LOC - e.g., Errors/KLOC, Defects/KLOC, Cost/LOC, Docs pages/KLOC

Proposed by early SE measurement.

Contrast:

Function-oriented metrics = based on Function Points (number of functions, inputs, outputs, inquiries - Albrecht) → (i) & (ii) are function-point related, not size-oriented.

Memory usage (iv) is performance metric, not size-oriented.

Answer: (iii) number of lines of code
Q1h. Which one of the following is not desired in a good Software Requirement Specifications (SRS) document? (i) Functional requirements (ii) Non-functional requirements (iii) Goals of implementation (iv) Algorithms for software implementation20202m
Module 2: Requirements & SRS
Which one of the following is not desired in a good Software Requirement Specifications (SRS) document?

(i) Functional requirements
(ii) Non-functional requirements
(iii) Goals of implementation
(iv) Algorithms for software implementation

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iv) Algorithms for software implementation

Explanation

A good SRS (IEEE 830) should be Correct, Unambiguous, Complete, Consistent, Ranked, Verifiable, Modifiable, Traceable.

It SHOULD contain:

Functional requirements (what system does) - (i) required

Non-functional requirements (performance, reliability, portability) - (ii) required

Goals of implementation (purpose, scope) - (iii) included at high level

It SHOULD NOT contain:

(iv) Algorithms for implementation - This is design detail. SRS is what not how. Algorithm, architecture, data structures are decided in design phase, not requirements. Including them makes SRS over-constrained and reduces designer freedom.

Answer: (iv) Algorithms for software implementation
Q1i. A software organization has been assessed at SEI CMM Level 4. Which of the following does the organization need to practice beside Process Change Management and Technology Change Management in order to achieve Level 5? (i) Defect detection (ii) Defect prevention (iii) Defect isolation (iv) Defect propagation20202m
Module 4: Software Testing
A software organization has been assessed at SEI CMM Level 4. Which of the following does the organization need to practice beside Process Change Management and Technology Change Management in order to achieve Level 5?

(i) Defect detection
(ii) Defect prevention
(iii) Defect isolation
(iv) Defect propagation

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (ii) Defect prevention

Explanation

SEI CMM Levels:

Initial 2. Repeatable 3. Defined 4. Managed (Quantitative Process Management + Software Quality Management) 5. Optimizing

To go Level 4 → Level 5, three Key Process Areas (KPAs) must be added:

Defect Prevention

Technology Change Management

Process Change Management

Question says org is at Level 4 and already practices Process Change + Technology Change → remaining KPA is Defect Prevention.

Defect detection/isolation/propagation are not CMM KPAs (distractors).

Answer: (ii) Defect prevention
Q1j. ______ is a measure of the degree of interdependence between modules. (i) Cohesion (ii) Coupling (iii) None of the above (iv) All of the above20202m
Module 3: Software Design & Metrics
______ is a measure of the degree of interdependence between modules.

(i) Cohesion
(ii) Coupling
(iii) None of the above
(iv) All of the above

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (ii) Coupling

Explanation

Coupling = Measure of interdependence between modules. Low coupling is desired (modules independent, change in one less likely to affect other). Types: Data, Stamp, Control, External, Common, Content (worst).

Cohesion = Measure of intra-dependence / how strongly elements within a single module belong together. High cohesion is desired. Types: Functional (best) → Sequential → Communicational → Procedural → Temporal → Logical → Coincidental (worst).

Answer: (ii) Coupling

Q2a. What is waterfall model for software development? Explain the situation, in which the spiral model for software development should be preferred over waterfall model.20207m

Module 1: Introduction & SDLC

What is waterfall model for software development? Explain the situation, in which the spiral model for software development should be preferred over waterfall model.

View this question on its own page →

Search Google Ask AI

Worked Solution

Definition: Oldest SDLC, proposed by Winston Royce (1970). Phases in linear cascade where each phase must complete before next begins. Output of one is input to next. No overlap.

Phases:
Requirements → System & Software Design → Implementation (Coding) → Testing (Verification) → Deployment → Maintenance

Requirements
     ↓
  Design
     ↓
Implementation
     ↓
 Verification
     ↓
 Maintenance

Characteristics: Simple, document-driven, easy to manage. Each phase has review & gate.

Spiral is risk-driven, iterative, incremental (Barry Boehm, 1986). Four quadrants per loop: Objective setting, Risk analysis, Development, Planning.

Prefer Spiral when:

Condition	Why Waterfall fails
High risk / unknown requirements	Waterfall assumes frozen requirements
Large, complex, innovative projects	Spiral prototypes & risk mitigation each loop
Requirements change frequently	Waterfall costly to change later
Need early risk detection (technical/feasibility)	Waterfall discovers risk late in testing
Long-term projects needing incremental releases	Spiral gives successive prototypes
Budget / cost uncertainty	Spiral evaluates cost-risk each cycle

Example Situations:

New OS / AI product where feasibility unknown
Defence / aerospace where failure cost high
Startup product with evolving customer needs

Conclusion: Use Waterfall for small, well-understood, stable-requirement projects (e.g., payroll system). Use Spiral for large, risky, complex projects.

Budget App•POCKETLY
Pocketly on Android
Log daily food, travel, and hostel expenses instantly. Set monthly spending limits and see where your money goes without complex spreadsheets.
Install Pocketly
Q2b. A program is to be developed to simulate the operations of a scientific calculator. List the facilities to be provided by this calculator. Analyze this using a DFD 0-level and 1-level diagram.20207m
Module 3: Software Design & Metrics
A program is to be developed to simulate the operations of a scientific calculator. List the facilities to be provided by this calculator. Analyze this using a DFD 0-level and 1-level diagram.

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Facilities for Scientific Calculator

Basic: Addition, Subtraction, Multiplication, Division, %,
Scientific: sin/cos/tan, log/ln, $x^y$ , $\\sqrt{}$ , $n!$ , $\\pi$ , $e$ , brackets, DEG/RAD mode, memory (M+/MR/MC), history, error handling (divide by zero).

DFD Level 0 (Context Diagram)

External Entity: User

Process: 0 - Scientific Calculator System

Data Flows: Input Expression / Key Press → System → Result / Error Display

Input (keys/expression) User ─────────────────────►│ 0. Scientific Calculator │─────────────────────► User (Result/Error) │ System │

DFD Level 1 (Decomposition)

Processes:

1.0 Accept Input - validate keys/expression

2.0 Parse & Convert - infix to postfix / syntax tree, handle brackets

3.0 Compute - ALU + Scientific engine (trig/log/power)

4.0 Display & Memory - show result, update memory/history

Data Stores:

D1 Memory Store (M values)

D2 History Log

User → 1.0 Accept Input → 2.0 Parse → 3.0 Compute → 4.0 Display → User ↕ ↕ ↕ D2 D1 D2

Description:

1.0 checks valid tokens, prevents illegal sequence.

2.0 handles operator precedence, RAD/DEG conversion.

3.0 calls math library; on error (div/0, domain) routes to error flow.

4.0 formats output, manages M+/MR and history scroll.

This satisfies function-oriented analysis for the calculator simulation program.
Q5a. Explain the roles and responsibilities of the following personnels in the s/w development process: (i) Project Manager (ii) Project Leader (iii) System Analyst (iv) Developer20207m
Module 1: Introduction & SDLC
Explain the roles and responsibilities of the following personnels in the s/w development process:

(i) Project Manager
(ii) Project Leader
(iii) System Analyst
(iv) Developer

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

(i) Project Manager

Role: Overall leadership, responsible for success/failure.
Responsibilities: Project planning, scheduling, budgeting, resource allocation, risk management, stakeholder communication, monitoring & control, delivery & closure. Makes go/no-go decisions.

(ii) Project Leader / Team Lead

Role: Technical lead for a module/team, bridge between manager and developers.
Responsibilities: Task breakdown & assignment, technical guidance, code reviews, daily stand-ups, resolving technical impediments, status reporting to PM, ensuring quality & deadlines for his team.

(iii) System Analyst

Role: Bridge between customer and development team.
Responsibilities: Requirement elicitation & analysis, feasibility study, modelling (DFD/ERD/UML), preparing SRS, prototyping, validating requirements with client, assisting in system design. Ensures what to build is correct.

(iv) Developer / Programmer

Role: Implements the system.
Responsibilities: Detailed design, coding as per standards, unit testing, debugging, documentation, integration support, maintenance fixes. Follows coding guidelines and participates in reviews.

Together they form the classic hierarchy: Manager → Leader → Analyst → Developer covering management, analysis, and construction.
Q5b. Design the following for an 'E-commerce solution for an electronic products company' that gives choice to the users to select a/few product(s) from the available range, order them and allow to make the payments online: (i) Design the DFDs (level-0, 1 and 2). (ii) Prepare SRS document. List assumptions, if any. (iii) Design an ER-diagram. List all the entities, attributes, key constraints and cordiality. (iv) Draw a Gantt chart. (v) Specify the s/w engineering pre-design which suits this application development.20207m
Module 3: Software Design & Metrics
Design the following for an 'E-commerce solution for an electronic products company' that gives choice to the users to select a/few product(s) from the available range, order them and allow to make the payments online:

(i) Design the DFDs (level-0, 1 and 2).
(ii) Prepare SRS document. List assumptions, if any.
(iii) Design an ER-diagram. List all the entities, attributes, key constraints and cordiality.
(iv) Draw a Gantt chart.
(v) Specify the s/w engineering pre-design which suits this application development.

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution - E-commerce for Electronic Products

(i) DFDs

Level 0 (Context): External Entities: Customer, Admin, Payment Gateway. Process: E-commerce System. Flows: Browse/Search, Order, Payment, Confirmation, Inventory update.

Level 1: Processes: 1.0 User Management & Authentication, 2.0 Catalog & Search, 3.0 Cart & Ordering, 4.0 Payment Processing, 5.0 Order Fulfillment & Shipping. Data Stores: D1 User DB, D2 Product Catalog, D3 Cart/Orders, D4 Payments.

Level 2 (example for 3.0 Cart & Ordering): 3.1 Add to cart, 3.2 Update quantity, 3.3 Calculate total + tax + discount, 3.4 Checkout & address validation.

(ii) SRS (Outline, IEEE 830)

1. Introduction: Purpose, Scope, Definitions (SKU, Cart), References, Overview
2. Overall Description: Product perspective, User classes (Guest/Customer/Admin), Constraints (PCI-DSS), Assumptions (Internet, payment gateway available)
3. Specific Requirements:

Functional: Registration, login, search/filter, product details, cart, wishlist, checkout, payment (COD/Card/UPI), order tracking, admin CRUD, reports

Non-functional: Performance <2s, security (HTTPS, encrypted), availability 99.5%, usability, scalability

Interfaces: UI, hardware, software (DB, gateway API)
Assumptions: Delivery partners available, returns within 7 days.

(iii) ER Diagram

Entities & Attributes:

User(user_id PK, name, email, password, address, phone)

Product(product_id PK, name, category, price, stock, specs, warranty)

Cart(cart_id PK, user_id FK)

Cart_Item(cart_id FK, product_id FK, qty)

Order(order_id PK, user_id FK, date, total, status, payment_id FK, shipping_addr)

Order_Item(order_id FK, product_id FK, qty, price)

Payment(payment_id PK, method, amount, status, transaction_no)

Admin(admin_id PK, ...)

Key Constraints: PK as above, FK referential integrity.
Cardinality: User 1—N Cart (1 active), Cart 1—N Cart_Item, Product 1—N Cart_Item, User 1—N Order, Order 1—N Order_Item, Order 1—1 Payment.

(iv) Gantt Chart (6 months)

Phase M1 M2 M3 M4 M5 M6

Requirements ██

Design ██

Catalog & User Module ██

Cart/Payment ██

Testing ██

Deployment ██

Milestones at end of each bar.

(v) Suitable Process Model

Agile-Iterative (Scrum) + Incremental: E-commerce needs evolving features, UI feedback, frequent releases. Alternatives: Prototyping for UI validation. Waterfall too rigid for changing product requirements. Spiral if high risk payment integration.
Q6b. How are boundary conditions tested in black box testing? Explain with example.20207m
Module 4: Software Testing
How are boundary conditions tested in black box testing? Explain with example.

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Black Box Boundary Value Analysis (BVA)

Concept: Errors cluster at boundaries. Instead of random values, test at edges of equivalence partitions. For a range $[min, max]$ , test: $min, min+1, max-1, max, min-1, max+1$ (invalid).

How boundary conditions tested:

Identify input domain boundaries from SRS (e.g., age 18-60, array size 1-100)

Create equivalence partitions (valid / invalid)

Pick values: at boundary, just inside, just outside

For $n$ variables, $4n+1$ test cases (or $6n+1$ with invalid). Also robust BVA includes invalid.

Example: Program accepts marks 0-100, grade calculation.

Test Case Input Expected

Below lower -1 Invalid

At lower 0 Pass (F)

Just above lower 1 Pass

Mid 50 Pass

Just below upper 99 Pass

At upper 100 Pass (A)

Above upper 101 Invalid

Boundary coverage: Detects off-by-one errors like if (marks > 0 && marks < 100) incorrectly rejecting 0/100.

Advantage: Minimum test cases, maximum fault detection at edges where developers often use < vs <= incorrectly.
Q8a. Consider a large scale project for which the manpower requirement is K = 600PY and the development time is 3 years 6 months. (i) Calculate the peak manning and peak time. (ii) What is the manpower cost after 1 year and 2 months?20207m
Module 3: Software Design & Metrics
Consider a large scale project for which the manpower requirement is K = 600PY and the development time is 3 years 6 months.

(i) Calculate the peak manning and peak time.
(ii) What is the manpower cost after 1 year and 2 months?

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Given: $K = 600$ PY (Person-Years), $t_d = 3.5$ years = 42 months

Using Norden / Rayleigh / Putnam model (used in textbooks for this numerical):

Formulas:

Peak Manning $m_0 = \\frac{K}{t_d \\sqrt{e}} \\approx 0.606 \\frac{K}{t_d}$

Peak Time $t_0 \\approx \\frac{t_d}{\\sqrt{2}} \\approx 0.707 t_d$ (some books use $t_0 = t_d / 1.5$ )

Cumulative manpower up to time $t$ : $y(t) = K(1 - e^{-a t^2})$ with $a = 1/(2t_0^2)$

(i) Peak Manning & Peak Time

Using standard SE approximation (Jalote/Pressman variant):

$t_0 = 0.5 \\times t_d = 1.75$ years = 21 months (if assuming peak at mid-point, common simplified answer)

Alternate Rayleigh: $t_0 = t_d / \\sqrt{2} = 2.47$ years = 29.7 months

$m_0 = K/(t_d \sqrt{e}) = 600 / (3.5 \times 1.648) = 600 / 5.77 = 104 persons (approx)

If using Putnam $K = 600/3 =200$ PY per year? Some solutions state $m_0 \\approx 104-120$ persons, $t_0 \\approx 1.75-2.47$ years.

Exam expected answer (simplified): $t_0 = 1.75$ years, $m_0 \\approx 103-110$ persons. If using $t_d/\\sqrt{2}$ then $t_0=2.48$ years, $m_0 \\approx 92$ persons.

(ii) Manpower cost after 1 year 2 months ( $t = 1.17$ years)

$y(t) = K[1 - e^{-(t/t_0)^2}]$ approximation
For $t=1.17, t_0=2.47$ : $(t/t_0)^2 = 0.224$ , $e^{-0.224}=0.799$
$y=600(1-0.799)=600\times0.201= 120.6 PY consumed

Effort remaining $= K - y \\approx 480$ PY
Cost ∝ manpower; if rate $c$ per PY, cost incurred $\\approx 120c$ .

Using simplified $t_0=1.75$ : $(1.17/1.75)^2=0.447$ , $y=600(1-e^{-0.894})=600(1-0.409)=354$ PY? Variation shows model sensitivity - state assumption.

Note: Mention assumption clearly in exam; any of the standard Rayleigh/Norden derivations with formula is accepted.
Q8b. What are the risk management activities? Is it possible to prioritize the risks? Explain with suitable example.20207m
Module 1: Introduction & SDLC
What are the risk management activities? Is it possible to prioritize the risks? Explain with suitable example.

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Risk Management Activities (Boehm / SEI)

Risk Identification - List potential risks: product, project, business (e.g., staff turnover, requirement change, tech failure, schedule slippage). Techniques: checklist, brainstorming, Delphi.

Risk Analysis - Assess probability ( $P$ ) and impact ( $I$ ), exposure $RE = P \\times I$ . Qualitative vs quantitative.

Risk Prioritization / Ranking - Order by exposure; Pareto 80/20. High-exposure handled first.

Risk Planning / Mitigation - Avoid, transfer, reduce, accept. Contingency plans, prototypes, incremental delivery.

Risk Monitoring & Control - Track triggers, reassess, execute mitigation, status reports.

Risk Resolution / Mitigation Execution - Implement actions.

Some books group as: Assessment (Identification+Analysis+Prioritization) → Control (Planning+Resolution+Monitoring).

Is Prioritization Possible? YES

Yes, risks MUST be prioritized because resources limited.

Method:

Compute Risk Exposure = Probability × Impact (or Risk Leverage)

Build Risk Table sorted descending. E.g.:

Risk P Impact (1-5) RE Priority

Staff leaving 0.7 4 2.8 1

Requirement change 0.6 3 1.8 2

Tech not mature 0.3 5 1.5 3

High RE = high priority. Use risk matrix / cutoff.

Example: In E-commerce project, payment gateway integration failure (P=0.5, Impact=5, RE=2.5) is prioritized over minor UI delay (P=0.8, Impact=1, RE=0.8). Top risks get mitigation budget and weekly monitoring; low risks accepted.

Conclusion: Prioritization is not only possible but essential for effective risk management.
Q9a. What are the different architectural styles applied for software development? Explain with diagrams.20207m
Module 3: Software Design & Metrics
What are the different architectural styles applied for software development? Explain with diagrams.

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Architectural Styles (Sommerville/Pressman) - with Diagrams

1. Layered / N-Tier

Hierarchy of layers, each provides service to above. e.g., OSI, Web: Presentation → Business → Data.

[ UI Layer ] → [ Application ] → [ Data Layer ]

2. Client-Server

Clients request via network from centralized servers. 2-tier / 3-tier.

Client → Network → Server (DB/App)

3. Model-View-Controller (MVC)

Model (data), View (UI), Controller (logic). Used in Web frameworks.

4. Repository / Blackboard

Central data store, independent components operate on it. e.g., IDE, Compiler, CASE tool.

[Tool1] ↔ [Central Repository] ↔ [Tool2]

5. Pipe and Filter

Data stream passes through filters via pipes. e.g., Unix shell ps | grep | sort, Compilers.

Source → Filter1 | → Filter2 | → Sink

6. Event-Driven / Publish-Subscribe

Components communicate via events. e.g., GUI, IDE listeners.

7. Microservices / SOA

Independent deployable services with APIs. Modern cloud style.

Selection criteria: Data flow, control, distribution, modifiability. Most real systems are hybrid (e.g., Layered + Client-Server).

Test Case	Input	Expected
Below lower	-1	Invalid
At lower	0	Pass (F)
Just above lower	1	Pass
Mid	50	Pass
Just below upper	99	Pass
At upper	100	Pass (A)
Above upper	101	Invalid

Risk	P	Impact (1-5)	RE	Priority
Staff leaving	0.7	4	2.8	1
Requirement change	0.6	3	1.8	2
Tech not mature	0.3	5	1.5	3

Previous year2019 Next year2021

Budget AppAndroid App

Log daily food, travel, and hostel expenses instantly. Set monthly spending limits and see where your money goes without complex spreadsheets.

Install Pocketly

Requirements

Catalog & User Module

Cart/Payment

Deployment