৪৯তম বিসিএস ⎯ তথ্য ও যোগাযোগ প্রযুক্তি [২৮১]

The Software Development Life Cycle (SDLC) consists of phases like requirement analysis, design, development, testing, deployment, and maintenance. Marketing is not a part of SDLC; it is part of business or product management, but not directly tied to software development processes.

Example:
A typical SDLC flow might start with gathering requirements, then move to designing the software, followed by coding, testing, and deployment.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

The prototype model in software development involves creating an initial prototype or working model of the software. This prototype is developed quickly with just enough functionality to gather feedback from users. Based on the feedback, the prototype is refined iteratively until the final version of the software is developed.

Example:
A company developing a new customer relationship management (CRM) system might create a simple prototype, gather feedback from users on its features and usability, and then improve the prototype with additional features or changes before the final system is built.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

Software maintenance refers to the process of updating and improving software after it has been deployed. It includes bug fixing, updating features to keep up with changes in user needs or technology, and ensuring the software continues to meet its performance and functional requirements.

Example:
For a mobile app, software maintenance might include fixing a bug where the app crashes on certain devices or updating the app to ensure compatibility with a new operating system version.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

The primary goal of software testing is to ensure that the software works as intended and meets the user’s requirements. It involves identifying and fixing defects or bugs, verifying that the software performs correctly under different conditions, and ensuring it meets functional and non-functional requirements.

Example:
Testing a mobile app to ensure that all buttons are responsive, the app performs correctly on various screen sizes, and it handles edge cases such as no internet connection.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

The waterfall model is a linear and sequential software development methodology. It progresses through clearly defined phases, such as requirement analysis, design, implementation, testing, deployment, and maintenance. Once a phase is completed, the process moves to the next phase, with little to no overlap or revisiting of previous phases.

Example:
In a waterfall model, the software requirements are defined first, followed by design and development, and then testing happens only after development is complete.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

A use case in software engineering is a detailed description of how the system interacts with external entities (users, other systems) to achieve a specific goal. Use cases are used to capture functional requirements and are often represented in use case diagrams and described in use case narratives.

Example:
A use case for an online store could describe how a user adds an item to their cart, proceeds to checkout, and completes a purchase.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

A data flow diagram (DFD) is a commonly used technique in software design to represent how data flows through the system. It shows the flow of information between processes, data stores, and external entities, helping to visualize the system's functionality.

Example:
In the design of a banking system, a DFD might show how customer data flows between processes like account creation, balance inquiry, and transaction processing.

Source: Systems Analysis and Design by Shelly Cashman

The Agile model emphasizes iterative and incremental development. It focuses on delivering small, functional pieces of software at regular intervals (sprints). Agile methodologies like Scrum and Kanban are commonly used in software development for flexibility, frequent feedback, and continuous improvement.

Example:
In an Agile project, the development team might deliver a working version of the software every 1–4 weeks, allowing for user feedback and changes to be incorporated in the next sprint.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

The V-Model is an extension of the Waterfall model, where for each development stage, there is a corresponding testing phase. The development phases on the left side of the "V" (e.g., requirements, design) correspond to the testing phases on the right side (e.g., unit testing, integration testing). This ensures that testing activities are planned and conducted in parallel with development.

Example:
In the V-Model, as the system design is completed, test cases are also developed, and during coding, unit tests are prepared, ensuring that testing begins early and continues throughout the development process.

Source: Software Engineering by Ian Sommerville.

The Spiral model is advantageous because it allows for frequent revisions of the software as development progresses. Through iterative cycles, the Spiral model provides flexibility to accommodate changes and manage risks. Unlike the Waterfall model, where changes become more difficult after a phase is completed, the Spiral model allows for refinement and adjustment at each stage.

Example:
In a project using the Spiral model, if a risk is identified during one of the iterations, it can be addressed in the next cycle without significantly disrupting the overall project.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman.

Incremental development involves breaking the software development process into small, manageable pieces or increments. Each increment adds a portion of the functionality, and after each increment is completed, it is delivered to the client for feedback. This approach allows for regular updates and ensures that the software evolves in manageable steps.

Example:
In an Agile development process, each sprint represents an increment of the software, delivering a working version of the software at the end of the sprint.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

Rapid Application Development (RAD) is a software development paradigm that emphasizes:
Speed and Iteration: 
• RAD aims to develop software quickly through iterative prototyping rather than following a strict sequential approach.
User Involvement:
• Users are actively involved in requirements gathering, feedback, and testing throughout the process.
• This ensures that the software meets actual user needs and reduces the risk of rework.
Prototyping:
• RAD relies heavily on working prototypes that are refined in successive iterations.
Minimal upfront design:
 • Unlike Waterfall, RAD does not require extensive upfront documentation or detailed design.
• The focus is on building functional prototypes quickly and improving them based on feedback.

Example:
A RAD approach might be used for building a web application, where prototypes are developed quickly, and features are added incrementally based on ongoing user feedback.

Source: Software Engineering by Ian Sommerville

A major limitation of the Waterfall model is that it is rigid, and once a phase (like design or coding) is completed, it becomes difficult to go back and make changes. This model assumes that all requirements can be defined upfront, which is often not the case in dynamic, real-world projects.

Example:
In a Waterfall project for a banking application, if the requirements change after the coding phase has been completed, it would be difficult and costly to go back to the design phase.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

Strategic information supports decision-making that affects the long-term direction of the organization. It is often derived from aggregated data and analytics to guide policies, resource allocation, and future planning.

Example:
A company analyzing market trends to decide whether to expand into a new country is using strategic information.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

Tactical information:
i. Purpose: Helps managers and decision-makers plan and control medium-term actions to achieve specific organizational objectives.
ii. Timeframe: Typically covers weeks to months, unlike strategic information (long-term) or operational information (short-term).
iii. Use: Supports tactical planning, resource allocation, and implementation of strategies, often translating strategic goals into actionable plans.

Example:
A retail company wants to increase sales of a product in the next 3 months. Tactical information could include:
• Monthly sales reports
• Inventory levels
• Customer buying patterns
This information helps managers make medium-term decisions to achieve the sales target.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

Operational information is used for daily activities and routine decision-making. It is detailed, timely, and supports short-term goals and processes.

Example:
Processing employee attendance, managing daily sales, and tracking customer orders are examples of operational information usage.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

External information comes from outside the organization and is used to understand the environment, competition, and market conditions. It supports strategic and tactical decisions.

Example:
Analyzing reports on customer preferences, industry statistics, or competitor pricing strategies is using external information.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

Qualitative information describes attributes, opinions, or perceptions and cannot easily be measured numerically. It is often used to understand customer satisfaction, employee morale, or market perception.

Example:
Customer feedback comments, employee performance reviews, and focus group summaries are qualitative information.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

Real-time information refers to:
i. Immediate Processing: Data is collected, processed, and made available immediately as events happen.
ii. Use: Supports quick decision-making, monitoring, and control of ongoing operations.
iii. Characteristics:
• Highly time-sensitive
• Often integrated with systems that require instant updates, like stock trading systems, airline reservation systems, or online monitoring tools.

Example:
A bank monitoring ATM transactions:
• If a withdrawal occurs, the system immediately updates the account balance.
• This ensures accurate, real-time monitoring of customer accounts.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

Strategic information helps top management make long-term decisions that affect the direction of the organization. It often comes from a combination of internal and external sources and is usually high-level and summarized.

Example:
Market research reports, competitive analysis, and projected financial forecasts are used as strategic information.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

Operational information: It supports short-term, day-to-day activities.
Tactical information: It supports medium-term decisions for middle management.
Strategic information: It supports long-term decisions and planning for top management.

Example:
• Daily sales reports: operational
 • Quarterly inventory planning: tactical
 • Five-year market expansion strategy: strategic

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

A Work Breakdown Structure (WBS) divides a large project into smaller tasks or work packages. This helps in planning, assigning responsibilities, estimating time and costs, and tracking progress.

Example:
For a website development project:
• Project: E-commerce Website
• Task 1: Requirement Analysis
• Task 2: UI/UX Design
• Task 3: Backend Development
• Task 4: Testing
• Task 5: Deployment

Source: Software Engineering by Ian Sommerville

Project constraints, also known as the triple constraint, include scope, time, and budget. The programming language is a technical decision and not considered a constraint in project management terms.

Example:
Changing the project scope or extending the timeline can impact cost, but selecting Python or Java does not define the project's constraints.

Source: Software Engineering by Ian Sommerville

A Gantt chart is used to visualize the project schedule, showing the start and finish dates of tasks, overlapping activities, and progress over time. It helps managers track the timeline and monitor task completion.

Example:
A Gantt chart for a software project might show that coding starts on 1st July and ends on 30th July, while testing overlaps from 25th July to 5th August.

Source: Software Engineering by Ian Sommerville

Scope creep occurs when additional features, requirements, or tasks are added to a project without adjusting the time, budget, or resources. It can lead to delays and increased costs.

Example:
A client requests additional functionality after the project has begun, and the team implements it without updating the project plan, causing delays and extra cost.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

A deliverable is a tangible or intangible output produced as a result of completing a project or part of a project. In software engineering, this is usually the working software, documentation, or user manuals.

Example:
Deliverables for a mobile app project could include the fully functional app, user manual, and deployment guide.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

The Critical Path Method (CPM) is a project management technique used to identify task dependencies and determine the longest path of dependent activities that dictates the minimum project duration. It helps managers prioritize critical tasks and allocate resources efficiently.

Example:
In software development, coding must be completed before testing can begin. CPM identifies such dependencies to optimize project scheduling.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

Project metrics measure project-specific parameters, such as productivity, effort, schedule adherence, and resource utilization. Lines of code (LOC) per developer per week is a common metric used to track development productivity.

Example:
If a team produces 2000 lines of code per week, project managers can estimate the remaining effort required for the project.

Source: Software Engineering by Ian Sommerville

Software process metrics include measurements like defect density, mean time to repair (MTTR), and cyclomatic complexity, which evaluate software development efficiency and quality. Employee satisfaction, while important, is not a standard software process metric.

Example:
Defect density = Number of defects / Size of the code (e.g., per 1000 LOC)

Source: Software Engineering by Ian Sommerville

Cyclomatic complexity measures the number of linearly independent paths through a program’s source code, indicating its control flow complexity. It helps predict the number of test cases needed and potential maintenance difficulty.

Example:
A simple if-else statement increases cyclomatic complexity by 1, while nested loops increase it further.

Source: Software Engineering by Ian Sommerville

• MTTR (Mean Time To Repair) is a reliability and maintenance metric used in software and systems engineering.
• It represents the average time required to repair a system or fix a defect once a failure has occurred.
• Formula:
MTTR= [ Total downtime due to failures ] / [ Number of failures ]

• Purpose:
i. Measures how quickly a system can be restored to normal operation after a failure.
ii. Helps evaluate system maintainability and efficiency of support teams.

Example:
Suppose a software system experiences 4 failures in a month with downtime durations of 2, 3, 1, and 4 hours.
MTTR = [ 2+3+1+4 ]/4
          = 10/4
          = 2.5 hours
On average, it takes 2.5 hours to repair the system after a failure.

Source: Software Engineering by Ian Sommerville

Mean Time To Repair (MTTR) is calculated as
MTTR = [ Total downtime due to failures ] / [ Number of failures ]
           = [ 2+3+4+5 ]/4
           = 14/4
           = 3.5 
 ∴ MTTR = 3.5 hours
This means, on average, it takes 3.5 hours to repair the system after each failure.

Source: Software Engineering by Ian Sommerville

Function points measure the size of software based on functionality delivered to the user, including inputs, outputs, user interactions, files, and interfaces. This metric is independent of the programming language and helps estimate effort, cost and productivity.

Example:
A system with 10 user inputs, 5 outputs, and 3 user interfaces can be assigned function points for development effort estimation.

Source: Software Engineering by Ian Sommerville

Schedule variance compares the planned schedule with the actual progress. Positive variance indicates the project is ahead, negative variance indicates it is behind schedule. It is important for project monitoring and control.

Example:
If a task was planned to complete in 10 days but finishes in 12 days, schedule variance = 10 – 12 = -2 days (behind schedule).

Source: Software Engineering by Ian Sommerville

Function Point Analysis (FPA) estimates software project effort by evaluating the functionality provided to users, independent of programming language. It helps in effort, cost, and schedule estimation.

Example:
A system with 10 user inputs, 5 outputs, and 3 interfaces can be assigned function points to estimate development effort.

Source: Software Engineering by Ian Sommerville

Software project risks include anything that may adversely affect cost, schedule, scope, or quality. Changes in requirements are a common risk, leading to potential delays and increased costs.

Example:
If a client adds new features midway, the project plan must be revised to accommodate extra work.

Source: Software Engineering by Ian Sommerville

The MoSCoW method is a prioritization technique where tasks are classified as Must have, Should have, Could have, and Won’t have. It helps allocate resources to the most critical activities first.

Example:
For a project:
Must have: User authentication
Should have: Search feature
Could have: Chat support
Won’t have: Dark mode (for this iteration)

Source: Software Engineering by Ian Sommerville

Project scheduling involves planning the start and end times of all project activities, assigning resources, and ensuring the project is completed within the planned timeline.

Example:
Scheduling coding for weeks 1–4, testing for weeks 3–5, and deployment in week 6 ensures proper timeline management.

Source: Management Information Systems by Kenneth C. Laudon and Jane P. Laudon

Assigning responsibilities to objects involves defining what each object knows (attributes) and what each object can do (methods). Proper responsibility allocation ensures cohesion within objects and clarity in design.

Example:
In a banking system, an Account object has attributes like balance and methods like deposit() and withdraw(). These responsibilities are clearly assigned to the Account object.

Source: Applying UML and Patterns by Craig Larman

A responsibility defines a task or obligation that an object must fulfill. This can include providing information, performing an action, or collaborating with other objects.

Example:
In a library system, a Book object is responsible for providing details like title, author, and availability status.

Source: Applying UML and Patterns by Craig Larman

Clear responsibilities ensure that each object has a single, well-defined purpose, which improves cohesion, makes the design easier to understand, and simplifies maintenance and future enhancements.

Example:
Separating Account and Customer responsibilities prevents the Account object from managing personal customer details, improving cohesion and maintainability.

Source: Applying UML and Patterns by Craig Larman

The SOLID principles guide object-oriented design, especially the Single Responsibility Principle, which states that an object should have one reason to change i.e. a single, well-defined responsibility.

Example:
A Payment Processor object handles payment operations only, while a Report Generator object handles reporting. They are separated to follow the Single Responsibility Principle.

Source: Applying UML and Patterns by Craig Larman

SRP (Single Responsibility Principle) is one of the SOLID principles in software engineering and object-oriented design.
Meaning: Every class or module should have only one reason to change, i.e., it should have only one responsibility.
Purpose:
• Improves maintainability and readability of code.
• Reduces coupling between components.

Example:
 • Suppose you have a class that:
i. Manages user data (CRUD operations)
ii. Sends email notifications
 • According to SRP, this class violates SRP because it has two responsibilities.
 • Correct approach:
i. One class for user data management
ii. Another class for sending email notifications

Source: Applying UML and Patterns by Craig Larman

GRASP stands for General Responsibility Assignment Software Patterns, a set of nine principles used to guide the assignment of responsibilities to objects in object-oriented design. These patterns help in designing effective and maintainable software systems.
The nine GRASP patterns are:
i. Information Expert
ii. Creator
iii. Controller
iv. Low Coupling
v. High Cohesion
vi. Polymorphism
vii. Pure Fabrication
viii. Indirection
ix. Protected Variations
These patterns provide a framework for making design decisions about responsibilities and collaborations between objects.

Source: Applying UML and Patterns by Craig Larman

By assigning responsibilities to the object that already contains the relevant data, the Information Expert pattern minimizes the need for other objects to access that data, reducing coupling between objects. This leads to a more modular and maintainable system.

Example:
In a Library Management System, a Book object would handle all its internal attributes (title, author, due date), avoiding the need for external objects to access or manipulate its data directly.

Source: Applying UML and Patterns by Craig Larman

High cohesion means that an object is focused on a specific responsibility. In this case, the Customer object has a single responsibility, which is to manage customer contact information. It is not overloaded with unrelated tasks like payment processing or authentication.

Example:
A Customer object should not handle tasks like managing payment methods, which could be the responsibility of a Payment Method object.

Source: Applying UML and Patterns by Craig Larman

Low coupling encourages minimizing the dependencies between objects. Objects should interact with each other through well-defined interfaces, and each object should be as independent as possible to reduce the impact of changes and improve system flexibility.

Example:
In a Library Management System, the Book object should not depend on the User object to perform its functions. Instead, both objects should interact through clearly defined interfaces for operations like borrowing and returning books.

Source: Applying UML and Patterns by Craig Larman

Function-based metrics focus on assessing the functionality of a software system, independent of the technology or programming language used. It helps estimate development effort, resources, and the overall complexity of the system by evaluating the functions and features the system delivers to the user.

Example:
A Function Point Analysis (FPA) is a function-based metric that evaluates the complexity of a system by counting the number of inputs, outputs, user interactions, files, and interfaces the system handles.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

Availability refers to the uptime of a system or application, meaning the percentage of time the system is fully operational and accessible for use. High availability is crucial for critical systems like banking, healthcare, and telecommunications.

Example:
An e-commerce website with 99.9% availability means that the website will be accessible for 99.9% of the time, and only 0.1% of the time it might be down for maintenance or due to failure.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman

A safety-critical system is one where failure or malfunction can result in significant harm to people, property, or the environment. A flight control system in an airplane is an example of such a system because failure can lead to loss of life and aircraft damage.

Example:
In aviation, software that controls the flight path, speed, and altitude of an aircraft must be fail-safe and undergo rigorous safety testing to ensure reliability.

Source: Software Engineering: A Practitioner's Approach by Roger S. Pressman