Activities in the Software Process Model and Techniques for Process Improvement

Introduction

A software process model is a simplified, abstract representation of a software development process. It describes the sequence of activities, actions, and tasks performed to develop and maintain a software product. All software process models, regardless of their specific structure, incorporate four fundamental process activities.

Activities Carried Out Within the Software Process Model

A. Software Specification (Requirements Engineering)

This activity focuses on understanding and defining what services are required from the system and identifying the constraints under which it must operate and be developed.

Sub-activities include:

The output of this stage is a Software Requirements Specification (SRS) document that serves as the contract between developers and customers.

B. Software Design and Implementation

This activity involves converting the specification into an executable system. It bridges the gap between what the system should do and how it will actually be built.

Sub-activities include:

• Architectural Design -- Identifying the overall structure of the system, the principal components (subsystems or modules), and their relationships
• Interface Design -- Defining the interfaces between system components so they can work together correctly
• Component Design -- Designing the detailed logic and functionality of each individual component
• Database Design -- Designing the data structures and how data will be stored and retrieved
• Coding / Implementation -- Translating the design into source code using a suitable programming language

C. Software Validation (Verification and Validation)

This activity ensures that the system conforms to its specification and genuinely meets the expectations and needs of the customer.

Sub-activities (Testing Stages) include:

Unit Testing
     |
     v
Integration Testing
     |
     v
System Testing
     |
     v
Acceptance Testing

Validation asks: "Are we building the right product?" Verification asks: "Are we building the product right?"

D. Software Evolution (Maintenance)

Software must adapt to changing customer needs and environments even after initial deployment. This activity recognizes that software development is not a one-time activity but a continuous process.

Types of maintenance include:

• Corrective Maintenance -- Fixing bugs and errors discovered after deployment
• Adaptive Maintenance -- Modifying the system to work in a new or changed environment (e.g., new OS, new hardware)
• Perfective Maintenance -- Adding new features or improving existing functionality and performance
• Preventive Maintenance -- Restructuring or rewriting code to prevent future problems

Diagram: The Four Core Activities

+------------------+     +------------------+     +------------------+     +------------------+
|   Specification  | --> | Design and       | --> |   Validation     | --> |    Evolution     |
|  (Requirements)  |     | Implementation   |     |    (Testing)     |     |  (Maintenance)   |
+------------------+     +------------------+     +------------------+     +------------------+
        ^                                                                           |
        |___________________________________________________________________________|
                          (Feedback and Change Requests)

Techniques to Improve the Software Process

Once the process is understood, organizations apply systematic techniques to improve quality, reduce cost, and increase efficiency.

1. Process Measurement and Metrics

• Collecting quantitative data such as defect rates, time per activity, cost per module, and productivity
• Metrics provide an objective basis for identifying weaknesses and tracking improvement over time

2. Process Analysis

• Analyzing the current process to identify bottlenecks, redundancies, and inefficiencies
• Techniques include process modeling and workflow analysis

3. Process Change and Optimization

• Introducing targeted changes to address problems identified during analysis
• Changes may involve reordering activities, adding new checkpoints, or removing unnecessary steps

4. CMM / CMMI (Capability Maturity Model Integration)

• A framework that defines five maturity levels (Initial, Managed, Defined, Quantitatively Managed, Optimizing) to guide organizations in systematically improving their processes
• Organizations assess their current level and work toward higher levels of process maturity

5. Automation of Process Activities

• Using CASE (Computer-Aided Software Engineering) tools, CI/CD pipelines, automated testing frameworks, and build tools to reduce manual effort and human error

6. Peer Reviews and Inspections

• Conducting formal code reviews, walkthroughs, and inspections to detect defects early, before they propagate to later stages where they are more costly to fix

7. Training and Skill Development

• Regularly training team members in new technologies, methodologies, and best practices to improve overall team capability

8. Adopting Best Practices and Methodologies

• Applying proven methodologies such as Agile, Lean Software Development, or Six Sigma to streamline processes and reduce waste

9. Feedback Loops and Retrospectives

• Collecting feedback after each iteration or project phase and using it to continuously refine and improve the process for future cycles

Conclusion

The software process model is built around four core activities: Specification, Design and Implementation, Validation, and Evolution. Each activity plays a critical role in delivering a high-quality software product. By applying improvement techniques such as process measurement, CMMI frameworks, automation, peer reviews, and continuous feedback, organizations can systematically enhance their software development process, leading to higher quality products, reduced costs, and improved team efficiency.

Online Entrance Examination System - UML Diagrams

Note: No specific reference notes were found for this topic. The following answer is based on standard UML modeling principles as taught in Software Engineering courses for BSc CSIT, Tribhuvan University.

Assumptions Made

1. The system allows students to register, log in, and attempt an online entrance exam.
2. An admin manages questions, sets exam schedules, and views results.
3. The system auto-evaluates answers and generates results.
4. An examiner/teacher can add and manage questions.
5. The exam has a timer; the system auto-submits when time expires.

1. Use Case Diagram

Actors

Use Cases

+---------------------------------------------------------------+
|           Online Entrance Examination System                  |
|                                                               |
|   [Register]          [Login]         [Logout]               |
|                                                               |
|   [View Exam Schedule]   [Start Exam]   [Answer Questions]   |
|                                                               |
|   [Submit Exam]       [View Result]   [View Scorecard]       |
|                                                               |
|   [Add Questions]     [Edit Questions] [Delete Questions]    |
|                                                               |
|   [Schedule Exam]     [Manage Users]  [Generate Report]      |
|                                                               |
|   [Auto Submit] (System/Timer)                               |
+---------------------------------------------------------------+

Student -----> Register
Student -----> Login
Student -----> View Exam Schedule
Student -----> Start Exam
Student -----> Answer Questions
Student -----> Submit Exam
Student -----> View Result
Student -----> View Scorecard

Examiner ----> Login
Examiner ----> Add Questions
Examiner ----> Edit Questions
Examiner ----> Delete Questions

Admin -------> Login
Admin -------> Schedule Exam
Admin -------> Manage Users
Admin -------> Generate Report
Admin -------> View Result

System ------> Auto Submit  <<extends>> Submit Exam

Submit Exam <<includes>> Evaluate Answers
Start Exam  <<includes>> Load Questions

Relationships Summary

• Start Exam includes Load Questions
• Submit Exam includes Evaluate Answers
• Auto Submit extends Submit Exam (triggered when timer expires)
• View Scorecard extends View Result

2. Class Diagram

+------------------+        +---------------------+
|      User        |        |       Exam          |
+------------------+        +---------------------+
| - userID: int    |        | - examID: int       |
| - name: String   |        | - title: String     |
| - email: String  |        | - duration: int     |
| - password: String|       | - totalMarks: int   |
| - role: String   |        | - scheduleDate: Date|
+------------------+        | - status: String    |
| + login()        |        +---------------------+
| + logout()       |        | + startExam()       |
| + register()     |        | + endExam()         |
+------------------+        | + getQuestions()    |
        |                   +---------------------+
        |                           |
   _____|_____               _______|_______
  |           |             |               |
+-------+ +--------+  +----------+   +-----------+
|Student| | Admin  |  | Question |   |  Result   |
+-------+ +--------+  +----------+   +-----------+
|-stuID | |-adminID|  |-quesID   |   |-resultID  |
|-grade | |-dept   |  |-quesText |   |-stuID     |
+-------+ +--------+  |-options[]|   |-examID    |
|+takeExam()|+scheduleExam()|correctAns||-score  |
|+viewResult()|+manageUser()|+getAnswer()|+grade |
+-------+ +--------+  +----------+   +-----------+
                                            |
                       +--------------------+
                       |   ExamAttempt      |
                       +--------------------+
                       | - attemptID: int   |
                       | - stuID: int       |
                       | - examID: int      |
                       | - startTime: Time  |
                       | - endTime: Time    |
                       | - answers[]: String|
                       +--------------------+
                       | + submitAnswers()  |
                       | + calculateScore() |
                       | + autoSubmit()     |
                       +--------------------+

Relationships

3. Sequence Diagram

Scenario: Student Takes and Submits an Exam

Student      LoginPage     ExamController    QuestionDB     Timer      ResultModule
   |              |               |               |            |             |
   |--login()---->|               |               |            |             |
   |              |--authenticate()|              |            |             |
   |              |<--success-----|               |            |             |
   |<--dashboard--|               |               |            |             |
   |              |               |               |            |             |
   |--startExam()->              |               |            |             |
   |              |--loadExam()-->|               |            |             |
   |              |               |--getQuestions()->          |             |
   |              |               |<--questionSet-|            |             |
   |              |               |--startTimer()------------->|             |
   |<---------questions displayed--|               |            |             |
   |              |               |               |            |             |
   |--answerQuestion()------------>|               |            |             |
   |              |               |--saveAnswer()->|            |             |
   |              |               |               |            |             |
   |              |               |<---timeExpired-------------|             |
   |              |               |--autoSubmit() |            |             |
   |--submitExam()---------------->|               |            |             |
   |              |               |--calculateScore()--------------------->|
   |              |               |<--score--------------------------------|
   |<---------result displayed-----|               |            |             |
   |              |               |               |            |             |

Reading the diagram: time runs downward, each vertical line is the lifetime of one object, and each horizontal arrow is a message. The student logs in through the login page, the exam controller loads the exam and pulls the question set from the question database, the timer is started, and answers are saved as they are given. Whichever happens first, the student submitting or the timer expiring, ends the attempt: autoSubmit() covers the timeout case, which is why the timer has its own lifeline. The result module then scores the attempt and the score is returned to the student.

Conclusion

The three diagrams describe the same online entrance examination system from three angles. The use case diagram is the behavioural outside view and fixes what the Student and the Admin can ask the system to do, the class diagram is the structural view and fixes the classes User, Student, Admin, Exam, Question, ExamAttempt and Result with their attributes, operations and relationships, and the sequence diagram is the interaction view and fixes the order in which those objects exchange messages while one exam is taken. Together they cover requirements, structure and behaviour, which is why UML models are normally drawn as a set rather than singly.

Test Driven Development (TDD)

Note: No specific reference notes were found for this topic. The following answer is based on standard Software Engineering curriculum content appropriate for BSc CSIT, Tribhuvan University.

Definition

Test Driven Development (TDD) is a software development approach in which test cases are written before the actual code is written. The developer first writes a failing test, then writes the minimum amount of code to pass that test, and finally refactors the code. This cycle is repeated throughout the development process.

TDD follows the principle: "Write tests first, then write code to satisfy those tests."

The TDD Cycle (Red-Green-Refactor)

The core process of TDD follows three repeating steps:

1. RED    --> Write a test that FAILS (feature not yet implemented)
2. GREEN  --> Write just enough code to PASS the test
3. REFACTOR --> Clean up the code without breaking the test

This cycle is also known as the "Red-Green-Refactor" cycle.

Steps in TDD Process

1. Add a Test

   • Before writing any functional code, write a test case for the new feature or function.
   • The test will fail initially because the feature does not exist yet.

2. Run All Tests

   • Run the test suite to confirm the new test fails (Red phase).
   • This verifies the test is valid and the feature is truly missing.

3. Write the Code

   • Write the minimum amount of code necessary to make the failing test pass.
   • Do not write extra or unnecessary code at this stage.

4. Run Tests Again

   • Run all tests to confirm the new test now passes (Green phase).
   • Ensure no existing tests are broken.

5. Refactor the Code

   • Clean up the code: remove duplication, improve readability, optimize structure.
   • Run tests again to ensure refactoring did not break anything.

6. Repeat

   • Repeat the cycle for the next feature or requirement.

Diagram of TDD Cycle

        +------------------+
        |  Write a Test    |  <--- (Test Fails - RED)
        +--------+---------+
                 |
                 v
        +------------------+
        |  Write Code to   |  <--- (Test Passes - GREEN)
        |  Pass the Test   |
        +--------+---------+
                 |
                 v
        +------------------+
        |  Refactor Code   |  <--- (Clean Code - REFACTOR)
        +--------+---------+
                 |
                 v
           (Repeat Cycle)

Advantages of TDD

Disadvantages of TDD

Summary

Conclusion: TDD is a powerful development methodology that improves code quality, reduces bugs, and increases developer confidence. However, it requires discipline, proper training, and is most effective when applied consistently throughout the development lifecycle.

Software Pricing Strategies

Note: No specific reference notes were found for this topic. The following answer is based on standard Software Engineering curriculum covered in BSc CSIT.

Software Pricing

Software pricing refers to the strategies and methods used by software vendors to determine how much to charge customers for their software products or services.

Different Ways of Software Pricing

1. Cost-Based Pricing

• The price is determined by calculating the total cost of development (labor, hardware, overhead) and adding a profit margin.
• Formula: Price = Total Cost + Profit Margin
• Simple and straightforward but does not consider market competition.

2. Market-Based (Competitive) Pricing

• Price is set based on what competitors charge for similar software.
• The vendor analyzes the market and prices the product competitively.
• Suitable when there are many similar products available.

3. Value-Based Pricing

• Price is set according to the perceived value the software delivers to the customer.
• If the software saves significant time or money, a higher price can be justified.
• Common in enterprise and specialized software.

4. Subscription-Based Pricing

• Customers pay a recurring fee (monthly or annually) to use the software.
• Example: Microsoft 365, Adobe Creative Cloud.
• Provides steady revenue stream for vendors.

5. Freemium Pricing

• Basic version is offered free of charge; advanced features require payment.
• Attracts a large user base; revenue comes from premium upgrades.
• Example: Zoom, Spotify.

6. Per-User (License-Based) Pricing

• Price is charged per user or per seat that accesses the software.
• Common in enterprise software (e.g., CRM tools).
• More users = higher total cost.

7. Usage-Based (Pay-as-you-go) Pricing

• Customers are charged based on how much they use the software or its resources.
• Common in cloud services (e.g., AWS, Google Cloud).
• Flexible and scales with customer needs.

8. One-Time (Perpetual) License Pricing

• Customer pays a single upfront fee to use the software indefinitely.
• Traditional model used before cloud computing became popular.
• Example: Older versions of Microsoft Office.

Summary Table

Choosing the right pricing strategy depends on the type of software, target market, competition, and business goals of the organization.

Software Engineering Ethics and Practices

Note: No specific reference notes were found for this topic. The following answer is based on standard software engineering curriculum as taught in BSc CSIT programs, aligned with ACM/IEEE Software Engineering Code of Ethics.

Software Engineering Ethics and Practices

Software engineering ethics refers to the set of moral principles and professional standards that guide software engineers in their work. The ACM/IEEE Software Engineering Code of Ethics outlines eight key principles:

1. Public Interest (Public)

• Software engineers shall act consistently with the public safety, health, and welfare.
• They must disclose any risks to the public caused by software systems.
• Example: Ensuring safety-critical systems (medical, aviation) are thoroughly tested.

2. Client and Employer

• Engineers must act in the best interest of their client and employer, consistent with public interest.
• Maintain confidentiality of client information.
• Avoid conflicts of interest and be honest about capabilities.

3. Product Quality

• Engineers must ensure their products meet the highest professional standards.
• Write correct, well-documented, and maintainable code.
• Perform proper testing and quality assurance.

4. Judgment (Professional Integrity)

• Maintain integrity and independence in professional judgment.
• Avoid deceptive practices, falsifying data, or misrepresenting facts.
• Acknowledge and correct errors honestly.

5. Management

• Software engineering managers shall promote ethical management of software development.
• Ensure fair treatment of team members.
• Provide realistic project estimates and avoid unreasonable pressure.

6. Profession

• Advance the integrity and reputation of the profession.
• Contribute to the professional community through knowledge sharing.
• Avoid actions that bring disrepute to the profession.

7. Colleagues

• Be fair and supportive to colleagues.
• Share knowledge, give proper credit, and avoid undermining others.
• Report unethical behavior of colleagues when necessary.

8. Self (Lifelong Learning)

• Participate in lifelong learning and continuous professional development.
• Stay updated with new technologies, tools, and practices.
• Improve skills to maintain professional competence.

Summary Table

Key Point: These ethics ensure that software engineers remain responsible, honest, and professional in all aspects of their work, protecting both users and society from harm caused by software failures or malpractice.

Short Notes

a) Non-Functional Requirements

Non-functional requirements (NFRs) define the quality attributes and constraints of a system rather than specific behaviors or functions. They describe how the system performs its functions, not what it does.

Key Characteristics:

• Also called quality requirements or system quality attributes
• They apply to the system as a whole, not to individual features
• Failure to meet NFRs can make the entire system unacceptable

Common Types of Non-Functional Requirements:

Importance:

• They constrain the design and implementation choices
• They are often more critical than functional requirements
• They are typically measurable and testable

b) Principles of Agile

Agile is a software development philosophy based on iterative development, collaboration, and flexibility. The Agile Manifesto (2001) defines 12 guiding principles:

Core Values (Agile Manifesto):

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The 12 Principles of Agile:

1. Customer Satisfaction - Highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome Change - Welcome changing requirements, even late in development.

3. Frequent Delivery - Deliver working software frequently (weeks rather than months).

4. Collaboration - Business people and developers must work together daily throughout the project.

5. Motivated Individuals - Build projects around motivated individuals; give them the environment and trust they need.

6. Face-to-Face Communication - The most efficient method of conveying information is face-to-face conversation.

7. Working Software - Working software is the primary measure of progress.

8. Sustainable Development - Agile processes promote sustainable development at a constant pace.

9. Technical Excellence - 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. Self-Organizing Teams - The best architectures, requirements, and designs emerge from self-organizing teams.

12. Regular Reflection - At regular intervals, the team reflects on how to become more effective and adjusts accordingly.

Key Benefit:

Agile allows teams to adapt quickly to changing requirements, deliver value incrementally, and maintain high quality through continuous feedback and improvement.