BSc CSIT (TU) Science Software Engineering (BSc CSIT, CSC364) Question Paper 2074 Nepal

Software Process Model

A software process model is an abstract, simplified representation of the software process that describes the activities, their ordering, and the deliverables produced when developing software. It provides a framework for organizing, planning, and controlling development. Common examples include the Waterfall model, Incremental/Evolutionary model, Spiral model, and Agile models.

Fundamental Software Process Activities

Every process model is built from four fundamental activities:

1. Software Specification (Requirements Engineering)

Defining what the system should do and the constraints on its operation. Sub-activities include feasibility study, requirements elicitation and analysis, requirements specification, and requirements validation. Example: For an online banking app, gathering requirements such as fund transfer, balance enquiry, and security constraints.

2. Software Design and Implementation

Converting the specification into an executable system. Design covers architectural, interface, component, and database design; implementation translates the design into program code. Example: Designing the database schema and modules of the banking app, then coding them in Java.

3. Software Validation (Verification & Validation)

Checking that the software conforms to its specification and meets customer needs, mainly through testing (unit, integration, system, acceptance testing). Example: Testing that a fund transfer correctly debits one account and credits another.

4. Software Evolution (Maintenance)

Modifying the software to meet changing customer and market requirements after delivery. Example: Updating the banking app to support a new tax rule or mobile OS version.

Conclusion

A process model arranges these activities in different orders and iterations. The choice of model depends on project size, requirement stability, and risk, but all models must perform specification, design/implementation, validation, and evolution.

UML Models for an Online Book Recommendation System

The system lets users register, browse books, rate books, and receive personalized recommendations generated by a recommendation engine.

(a) Use Case Diagram

Actors: User (Reader), Administrator, Recommendation Engine (secondary actor).

Use cases (described, since a figure cannot be drawn here):

• User: Register/Login, Search Book, View Book Details, Rate/Review Book, Get Recommendations, Manage Profile.
• Administrator: Add/Update/Delete Book, Manage Users, View Reports.
• Get Recommendations <<include>> View User Ratings History; Rate Book <<extend>> Write Review.

        +------------------------------------------+
        |        Book Recommendation System        |
        |  (Register/Login)                        |
  User--|  (Search Book)   (View Book Details)     |--Admin
        |  (Rate Book)     (Get Recommendations)   |
        |  (Manage Books)  (Manage Users)          |
        +------------------------------------------+

(b) Class Diagram

Main classes with attributes and relationships:

Relationships:

• User 1 --- * Rating (a user gives many ratings).
• Book 1 --- * Rating (a book receives many ratings).
• RecommendationEngine --- uses --- Rating and produces Recommendation for a User (User 1 --- * Recommendation).

(c) Sequence Diagram — Get Recommendations

Order of messages (lifelines: User, UI, RecommendationEngine, RatingDB, BookDB):

User -> UI: requestRecommendations()
UI -> RecommendationEngine: generateRecommendations(userId)
RecommendationEngine -> RatingDB: getUserRatings(userId)
RatingDB --> RecommendationEngine: ratingsList
RecommendationEngine -> BookDB: getCandidateBooks(genre)
BookDB --> RecommendationEngine: bookList
RecommendationEngine -> RecommendationEngine: computeScores()
RecommendationEngine --> UI: recommendedBooks
UI --> User: display recommendations

This shows the synchronous flow from the user request through the engine querying ratings and books, scoring, and returning the recommended list.

Importance of Software Pricing

Software pricing is the activity of setting the price charged to a customer for a software product. It is important because:

• It must cover the cost of development plus an acceptable profit.
• It is influenced not only by cost but by market conditions, competition, customer's financial health, and contractual risk.
• A price that is too high loses the contract; too low causes loss. Organizations may even price below cost (loss-leader) to gain a strategic foothold or future maintenance contracts.
• It affects the requirements and scope — sometimes functionality is negotiated to match a customer's budget.

COCOMO (Constructive Cost Model)

COCOMO is an algorithmic, empirical cost-estimation model proposed by Barry Boehm. It estimates effort, time, and cost as a function of the estimated size of the software in KLOC (thousands of lines of code).

Basic COCOMO

Effort and time are computed as:

The coefficients depend on the project mode:

Example: For an organic project of 10 KLOC: $E = 2.4 \times 10^{1.05} \approx 26.9$ person-months.

Intermediate & Detailed COCOMO

Intermediate COCOMO refines the estimate by multiplying by 15 cost-driver (EAF) attributes (product, hardware, personnel, project factors): $E = a(KLOC)^b \times EAF$. Detailed COCOMO applies cost drivers phase by phase.

Disadvantages of COCOMO

1. Relies on KLOC, which is hard to estimate accurately early in the project.
2. Ignores requirements volatility and changing specifications.
3. Does not account for personnel skill differences, hardware, or modern methods (it is dated for OO/agile development).
4. Estimates can be highly inaccurate if the project mode or cost drivers are wrongly chosen.
5. Does not consider factors like documentation quality, customer involvement, or reuse.

Software Engineering vs System Engineering

In short: System engineering looks at the entire system and how its parts (including software) fit together, whereas software engineering is the part of that effort dealing specifically with producing the software component.

Risk Management in Software Development

Risk management is the process of identifying, analyzing, and controlling risks (uncertain events that may adversely affect cost, schedule, or quality) throughout a project. Risks are classified as project risks (schedule/resource), product risks (quality of deliverable), and business risks (organizational/market). It is carried out as a continuous four-stage cycle:

1. Risk Identification

List possible project, product, and business risks (e.g. staff turnover, requirements change, technology immaturity, size underestimation). Checklists and brainstorming are used.

2. Risk Analysis

Assess each risk's probability (low/moderate/high) and impact/seriousness (catastrophic to insignificant) and prioritize them.

3. Risk Planning

Devise strategies to address key risks:

• Avoidance — reduce the probability the risk arises.
• Minimization — reduce the impact if it occurs.
• Contingency — prepare a fallback plan.

4. Risk Monitoring

Regularly review each risk to check whether its probability or impact has changed, and track the effect of mitigation. This is repeated at every milestone, and the risk register is updated.

Example: If "key staff leaving" is a high risk, the manager mitigates it by sharing knowledge and documenting work so others can continue.

Importance of Software Maintenance

Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve performance, or adapt it to a changed environment. It is one of the most important activities because:

• It consumes the largest share of the total software lifecycle cost (often 60-70%), as software is used for many years after release.
• Real-world environments constantly change — new hardware, operating systems, laws, and business rules force updates.
• It keeps software useful, reliable, and competitive over its lifetime.

Types of Maintenance

1. Corrective — fixing discovered bugs/defects.
2. Adaptive — adjusting to changes in environment (OS, hardware, regulations).
3. Perfective — adding new features or improving performance per user demand.
4. Preventive — restructuring/refactoring code to prevent future problems.

Example

Consider a payroll system in use for 10 years. When the government revises income-tax slabs, the tax-calculation module must be updated (adaptive/corrective maintenance); when users request online payslip download, a new feature is added (perfective). Without such ongoing maintenance the system would quickly become unusable — justifying maintenance as a critical, continuous activity.

Functional vs Non-Functional Requirements

Functional Requirements

Statements of the services the system must provide — how it should react to particular inputs and behave in particular situations. They define what the system does.

Examples:

• The user shall be able to search for books by title or author.
• The system shall generate a monthly sales report.
• The system shall allow a user to log in with a valid username and password.

Non-Functional Requirements

Constraints on the services or functions offered — they specify quality attributes and how well the system performs, rather than specific behaviours. They often apply to the system as a whole.

Examples:

• Performance: The system shall respond to a search within 2 seconds.
• Security: Passwords shall be stored using encryption.
• Usability/Reliability: The system shall have 99.9% uptime.
• Portability: The system shall run on Windows and Linux.

Comparison

Non-functional requirements are often more critical, since failing them may make the whole system unusable.

Prototyping Model in Software Development

A prototype is an early, working but incomplete version of a system built to help understand requirements and explore design options. The prototyping model develops such a prototype, gets user feedback, and refines it iteratively before building the final product.

How Prototyping Helps

1. Clarifies requirements: Customers often cannot state requirements precisely. A prototype lets them see and try the system, revealing missing, ambiguous, or wrong requirements early.
2. Improves communication: It provides a concrete basis for discussion between developers and users, reducing misunderstanding.
3. Reduces risk: Technical feasibility and design choices are tested early, lowering the chance of costly failures later.
4. Increases user satisfaction & acceptance: Users are involved throughout, so the final system better matches their needs.
5. Supports usability testing & training: The prototype can be used to evaluate the user interface and train staff before delivery.

Process

Gather initial requirements -> Build quick prototype -> User evaluates
          ^                                                |
          |------------- refine requirements <-------------+

The loop repeats until the prototype is acceptable, after which the full system is engineered (or the prototype is evolved into it).

Limitation: Excessive prototyping can be costly, and customers may mistake the prototype for the finished product.

Evolutionary vs Throw-away Prototyping

Both build a prototype to handle uncertain requirements, but differ in objective and fate of the prototype.

Evolutionary Prototyping

The aim is to deliver a working system. Development starts with the best-understood requirements, and the prototype is refined and extended incrementally into the final delivered system. The prototype is not thrown away.

Throw-away (Rapid) Prototyping

The aim is to understand and validate requirements, especially the poorly-understood ones. Once requirements are clarified, the prototype is discarded and the real system is built from scratch (often using proper engineering and quality standards).

Comparison

Summary: Evolutionary prototyping evolves the prototype into the product; throw-away prototyping uses the prototype only to learn requirements and then discards it.

Behavioural Model

A behavioural model describes the dynamic behaviour of a system — how it responds to events and how data flows through it as the system executes (i.e. what the system does over time), rather than its static structure. There are two main types:

1. Data-Driven (Data-Flow) Models

Show how input data is processed and transformed into output through a sequence of processing steps. Data Flow Diagrams (DFDs) are used.

Example — Order processing: A Customer Order flows into a Validate Order process, then to Check Stock, then to Generate Invoice, finally producing an Invoice output, with data stores such as Stock DB and Customer DB.

2. Event-Driven Models

Show how the system reacts to external/internal events and changes state. State machine / State transition diagrams are used.

Example — Microwave oven: States such as Idle -> Setting Time -> Cooking -> Finished. The event press Start causes a transition from Setting Time to Cooking; the event timer = 0 transitions from Cooking to Finished. In UML these are modelled with state diagrams, activity diagrams, and sequence diagrams.

Summary: Behavioural models (DFDs and state machines) capture the runtime behaviour of a system and complement structural models in requirements analysis and design.

Spiral Model

The Spiral model, proposed by Barry Boehm, is a risk-driven, iterative software process model. Instead of a fixed sequence of activities, the process is represented as a spiral in which each loop (cycle) represents one phase of development. It combines the iterative nature of prototyping with the systematic control of the waterfall model, with explicit risk analysis in every loop.

Four Quadrants of Each Loop

1. Objective Setting (Planning): Define objectives, alternatives, and constraints for that phase.
2. Risk Assessment and Reduction: Identify and analyze risks; build prototypes or simulations to resolve the highest risks.
3. Development and Validation: Develop and verify the next-level product (design, code, test) using the most suitable model.
4. Review and Planning: Review results with stakeholders and plan the next loop (next iteration of the spiral).

                Objective Setting | Risk Assessment
                ------------------+------------------
                Review/Plan next  | Develop & Validate
      (radius = cumulative cost, each loop = one phase)

Advantages

• Strong risk management — risks handled early in each cycle.
• Suitable for large, complex, high-risk projects.
• Supports incremental release and changing requirements.

Disadvantages

• Costly and complex; risk-analysis expertise required.
• Not suitable for small/low-risk projects.

Key Principles of Agile Methods

Agile methods focus on rapid, incremental delivery and responding to change rather than heavy up-front planning and documentation. The key principles are:

1. Customer involvement: Customers are closely and continuously involved throughout development to provide and prioritize requirements and evaluate iterations.
2. Incremental delivery: Software is developed and delivered in small increments, with the customer specifying the requirements for each increment.
3. People, not process: The skills of the development team are recognized and exploited; members work in their own way without prescriptive processes.
4. Embrace change: Requirements are expected to change, so the system is designed to accommodate changes rather than resist them.
5. Maintain simplicity: Focus on simplicity in both the software and the development process; actively eliminate unnecessary complexity.

These principles derive from the Agile Manifesto, which values individuals and interactions, working software, customer collaboration, and responding to change. Examples of agile methods include Extreme Programming (XP) and Scrum.