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

Importance of Software Pricing

Software pricing is the process of deciding how much to charge a customer for developing a software product. It is important because:

• Profitability and survival: The price must cover development cost plus a reasonable profit; mispricing can lead to loss or to losing the contract.
• Competitiveness: A price too high loses the bid to competitors; too low wins the bid but may make the project unviable.
• Risk coverage: Pricing must account for uncertainty in estimates, scope changes and contingency.
• Market positioning and customer relationship: A firm may deliberately price low to enter a market or to win a strategic customer, accepting a near-zero margin.

Unlike many goods, software price is not simply cost + margin. It is influenced by market conditions, contractual terms, the customer's ability to pay, and future business prospects.

COCOMO Cost Estimation Model

COCOMO (COnstructive COst MOdel), proposed by Barry Boehm (1981), is an algorithmic model that estimates effort, time and cost of a software project based on its estimated size in KLOC (thousands of lines of code).

Project classes

Basic COCOMO

Intermediate and Detailed COCOMO

• Intermediate COCOMO multiplies the nominal effort by an Effort Adjustment Factor (EAF) computed from 15 cost drivers (product, hardware, personnel and project attributes): $E = a(\text{KLOC})^{b} \times EAF$.
• Detailed COCOMO applies the cost drivers at each phase of the lifecycle for finer estimates.

Disadvantages of COCOMO

• Depends on an accurate KLOC estimate, which is hard to know early in the project.
• Ignores requirements volatility, documentation, and customer/team communication overhead.
• Based on historical (1970s-80s) data; may not fit modern languages, agile or reuse-heavy projects.
• Treats size as the dominant factor and gives little weight to hardware/personnel skills in the basic model.
• Subjective rating of cost drivers makes results estimator-dependent and less repeatable.

Requirements Engineering

Requirements engineering (RE) is the systematic process of discovering, analysing, documenting, validating and managing the services a software system should provide and the constraints under which it operates. Its output is the Software Requirements Specification (SRS).

Requirements Elicitation and Analysis Process

This is an iterative (spiral) process in which the analyst works with stakeholders to understand the application domain, the services required and the system constraints. It has four main activities that repeat in a cycle:

1. Requirements discovery (elicitation) – Interacting with stakeholders to gather their needs using techniques such as interviews, scenarios, use cases, ethnography (observation), questionnaires and prototyping.
2. Requirements classification and organisation – Grouping related requirements and structuring them into coherent clusters (e.g. by sub-system or architectural component).
3. Requirements prioritisation and negotiation – Resolving conflicts between stakeholders and ranking requirements by importance, since stakeholders' needs often clash.
4. Requirements specification (documentation) – Recording the requirements (formally or informally) to feed the next round of the cycle and ultimately the SRS.

Process diagram (described)

Imagine a circular/spiral flow: starting from Requirements discovery → Requirements classification and organisation → Requirements prioritisation and negotiation → Requirements documentation, with an arrow looping from documentation back to discovery. The whole loop spirals outward, producing a more complete SRS on each iteration until the requirements are agreed.

   Requirements --> Requirements --> Requirements --> Requirements
   discovery        classification    prioritisation    specification
      ^               & organisation   & negotiation         |
      |_______________________________________________________|
                 (iterate until SRS is complete)

Challenges: stakeholders may not know what they want, may express needs in their own terms, may give conflicting requirements, and requirements may change due to political/economic factors.

Software Testing

Software testing is the process of executing a program with the intent of finding defects and of demonstrating that the software meets its requirements. It is a key verification and validation (V&V) activity. Testing can only show the presence of errors, not their absence (Dijkstra).

Levels of Testing

Testing is carried out at progressively larger scopes:

1. Unit testing – Tests individual components/methods/classes in isolation to check they behave as designed. Usually done by developers.
2. Integration testing – Tests interactions between combined units/modules to expose interface defects (top-down, bottom-up or sandwich strategies).
3. System testing – Tests the complete, integrated system against the functional and non-functional requirements (performance, security, usability).
4. Acceptance testing – The customer/user verifies the system in a realistic environment to decide whether to accept it (alpha at developer site, beta at user site).

(Regression testing re-runs earlier tests after changes to ensure nothing is broken.)

Test-Driven Development (TDD)

TDD is an agile practice where tests are written before the code. Development proceeds in very short cycles, often called Red–Green–Refactor:

1. Write a small automated test for the next bit of functionality   (test FAILS - Red)
2. Run all tests and watch the new test fail
3. Write the minimum code to make the test pass                     (test PASSES - Green)
4. Run all tests to confirm they pass
5. Refactor the code to improve structure, keeping all tests green  (Refactor)
6. Repeat for the next piece of functionality

Benefits: code coverage is high by construction, defects are caught immediately, the test suite acts as living documentation and regression safety net, and the design tends to be simpler and more modular. Limitation: requires discipline and good test design, and is harder for UI/legacy/hard-to-test code.

Software engineering is concerned with the development and evolution of the software part of a system—requirements, design, implementation, testing and maintenance of programs and data. System engineering is broader: it concerns the development and evolution of a complete socio-technical system, including hardware, software, people, processes and organisational policies.

Example: Building an air-traffic control system is system engineering (radars, networks, controllers' workstations, staff procedures); writing the flight-tracking program that runs on it is software engineering.

Risk management is the process of identifying risks, assessing their likelihood and impact, and planning to avoid or minimise their effect on a software project. It is carried out continuously throughout development through four activities:

1. Risk identification – List possible project, product and business risks (e.g. staff turnover, requirements change, technology immaturity, schedule slip, budget overrun).
2. Risk analysis – Assess each risk's probability (low/moderate/high) and impact (insignificant to catastrophic) to compute its exposure.
3. Risk planning – Devise strategies for the most serious risks: avoidance (reduce probability), minimisation (reduce impact), and contingency plans (what to do if it occurs).
4. Risk monitoring – Regularly review identified risks, check whether their probability/impact has changed, and watch for new risks; repeat the cycle.

Risks are usually recorded in a risk register / risk table sorted by exposure. Example: “Key developer leaves” — probability moderate, impact serious; mitigation: cross-train staff and document work. Effective risk management lets managers act proactively rather than reacting to problems after they occur.

Software maintenance is the process of modifying a software product after delivery to correct faults, improve performance, or adapt it to a changed environment. It is one of the most important and costly activities—often consuming 60–70% of the total lifecycle cost—for the following reasons:

• Software evolves: business needs, laws and user expectations change continuously, so software must be updated to remain useful (Lehman's laws of continuing change and increasing complexity).
• No software is defect-free: latent bugs are discovered in operation and must be fixed (corrective maintenance).
• Changing environment: new hardware, operating systems or external interfaces require adaptive maintenance.
• Improvement demand: users request new features and better performance (perfective maintenance) and the code is restructured to ease future change (preventive maintenance).

Example: A payroll system must be modified every year when the government revises income-tax slabs. Without this maintenance the software would compute wrong salaries and become useless—showing that maintenance, not initial development, keeps the software valuable over its lifetime.

Functional requirements state what the system should do—the services, behaviour and outputs it must provide for given inputs. Non-functional requirements state how well the system must do it—the quality attributes and constraints on the services.

Non-functional requirements are often system-wide and may be more critical than individual functional ones, because failing them can make the whole system unacceptable.

Prototyping Model

A prototype is an early, working (often partial) version of a system built to explore requirements and demonstrate concepts. In the prototyping model, a prototype is developed quickly, shown to users, and refined through feedback before (or instead of) building the final system.

Typical steps

1. Gather initial/outline requirements
2. Quick design of the prototype
3. Build the prototype
4. User evaluation of the prototype
5. Refine requirements and prototype (iterate)
6. Engineer the final product once requirements are clear

How it helps software development

• Clarifies vague requirements – users see a tangible system and can say what they really want, reducing requirement misunderstandings.
• Early validation – design and feasibility problems are found early, when they are cheap to fix.
• Improves communication between developers and customers.
• Increases user acceptance because users are involved and the delivered system matches expectations.
• Reduces risk of building the wrong product.

Limitation: customers may mistake the prototype for the final product, and quick-and-dirty prototypes can lead to poor architecture if not managed.

Both build a prototype, but they differ in purpose and in what happens to the prototype afterwards.

Evolutionary prototyping keeps improving one prototype until it becomes the delivered system. Throw-away prototyping builds a prototype solely to elicit and validate requirements, then throws it away and engineers the real system properly. Example: a UI mock-up shown only to confirm screen layout is throw-away; a continuously extended order-processing system is evolutionary.

Behavioural Model

A behavioural model describes the dynamic behaviour of a system—how it responds to events and how data flows while it executes—rather than its static structure. It captures what the system does over time. Two common kinds are:

1. Data-driven models (Data Flow Diagrams, DFD) – show how input data is processed and transformed into output as it moves through a sequence of processing steps. Useful when behaviour is driven by data processing (e.g. order/transaction processing).
2. Event-driven models (State machine / State transition diagrams) – show how the system moves between states in response to external or internal events. Useful for real-time and control systems.

Example (event-driven / state model)

Consider a microwave oven:

[Idle] --press start (door closed)--> [Cooking]
[Cooking] --timer = 0--> [Idle]
[Cooking] --open door--> [Paused/Disabled]
[Paused] --close door--> [Cooking]

Here the oven's behaviour is modelled as states (Idle, Cooking, Paused) and transitions triggered by events (press start, timer expires, open/close door). This is a behavioural model because it specifies how the system reacts to events over time, which a structural model cannot show.

Spiral Model

The spiral model, proposed by Barry Boehm (1988), is an evolutionary, risk-driven process model in which development proceeds as a series of loops (spirals), each loop producing a more complete version of the software. Its defining feature is explicit risk analysis at the start of every loop.

The four quadrants (phases) of each loop

1. Objective setting – Identify objectives, alternatives and constraints for this phase.
2. Risk assessment and reduction – Identify and analyse risks; resolve the most serious ones (often using prototyping).
3. Development and validation – Choose a development model for this loop and build/test the next version of the product.
4. Planning – Review results and decide whether to continue; plan the next loop.

The radius of the spiral represents cumulative cost; the angular dimension represents progress through the loops.

   Plan next phase  |  Determine objectives,
                    |  alternatives, constraints
   -----------------+-----------------
   Develop & verify |  Evaluate alternatives,
   next-level prod. |  identify & resolve RISKS

Characteristics

• Advantages: strong risk management, suitable for large, complex, high-risk projects; supports prototyping and iterative refinement.
• Disadvantages: costly, complex to manage, and depends heavily on risk-assessment expertise; not ideal for small projects.

Agile methods are iterative, incremental approaches that emphasise rapid delivery of working software and responsiveness to change. Their key principles (from the Agile Manifesto and Sommerville) are:

1. Customer involvement – Customers are closely engaged throughout to provide and prioritise requirements and feedback.
2. Incremental delivery – Software is developed and delivered in small increments; the customer specifies the requirements for each increment.
3. People, not process – Recognise and exploit the skills of the development team; let members use their own working methods.
4. Embrace change – Expect requirements to change and design the system so that change is accommodated easily.
5. Maintain simplicity – Focus on simplicity in both the software and the development process; eliminate unnecessary complexity.

Underlying values: individuals and interactions over processes/tools, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan.