SEPM Question Paper solution May 2023

Q1 a) Define software engineering and explain umbrella activities. (sepm)

Software engineering is the discipline concerned with the systematic approach to the development, operation, and maintenance of software. It involves applying engineering principles and practices to software development, aiming to create reliable, efficient, and maintainable software systems.

Umbrella activities in software engineering refer to overarching processes that are applied throughout a software project to manage and control various aspects such as progress, quality, change, and risk. These activities ensure the smooth execution of the project and the delivery of a high-quality product. Here are the typical umbrella activities:

Software Project Tracking and Control: This activity enables the software team to monitor progress against the project plan and take necessary actions to maintain the schedule.
Risk Management: It involves identifying and assessing risks that may impact the project’s outcome or the quality of the product, and implementing strategies to mitigate those risks.
Software Quality Assurance: This activity defines and conducts various processes to ensure the quality of the software, including testing, code reviews, and quality audits.
Technical Reviews: Technical reviews are conducted to evaluate software engineering work products and identify errors before they propagate to the next stage of development.
Measurement: This activity involves defining and collecting process, project, and product measures to ensure that the software meets stakeholders’ needs and can be used in conjunction with other framework and umbrella activities.
Software Configuration Management: It focuses on managing changes throughout the software development process, ensuring that all changes are properly tracked, evaluated, and implemented.
Reusability Management: This activity defines criteria for reusing work products, including software components, and establishes mechanisms to achieve reusability.
Work Product Preparation and Production: Encompassing activities required to create various work products such as models, documents, logs, and forms, this ensures that all necessary artifacts are prepared and maintained throughout the project lifecycle.

Q1 b) Difference between white box and black box testing.

Black Box Testing	White Box Testing
It is a way of software testing in which the internal structure or the program or the code is hidden and nothing is known about it.	It is a way of testing the software in which the tester has knowledge about the internal structure or the code or the program of the software.
Implementation of code is not needed for black box testing.	Code implementation is necessary for white box testing.
It is mostly done by software testers.	It is mostly done by software developers.
No knowledge of implementation is needed.	Knowledge of implementation is required.
It can be referred to as outer or external software testing.	It is the inner or the internal software testing.
It is a functional test of the software.	It is a structural test of the software.
This testing can be initiated based on the requirement specifications document.	This type of testing of software is started after a detail design document.
No knowledge of programming is required.	It is mandatory to have knowledge of programming.
It is the behavior testing of the software.	It is the logic testing of the software.
It is applicable to the higher levels of testing of software.	It is generally applicable to the lower levels of software testing.
It is also called closed testing.	It is also called as clear box testing.
It is least time consuming.	It is most time consuming.
It is not suitable or preferred for algorithm testing.	It is suitable for algorithm testing.
Can be done by trial and error ways and methods.	Data domains along with inner or internal boundaries can be better tested.
Example: Search something on google by using keywords	Example: By input to check and verify loops
Black-box test design techniques-Decision table testingAll-pairs testingEquivalence partitioningError guessing	White-box test design techniques-Control flow testingData flow testingBranch testing
Types of Black Box Testing: Functional Testing Non-functional testing Regression Testing	Types of White Box Testing: Path Testing Loop Testing Condition testing
It is less exhaustive as compared to white box testing.	It is comparatively more exhaustive than black box testing.

src : https://www.geeksforgeeks.org/differences-between-black-box-testing-vs-white-box-testing/

Q1 c) Explain functional and non-functional requirements.

Answer : https://www.doubtly.in/q/explain-functional-functional-requirements/

Q1 d) Explain the golden rules for interface design.

Regardless of the domain, user interface, or intended device (computer, tablet or phone) for a particular website or application, there are certain universal “Golden Rules” of user interface design. These golden rules have been discussed in numerous publications over the years.

Theo Mandel describes the golden rules of user interface design in great detail in Chapter 5 of his book, “The Elements of User Interface Design.”

Mandel’s Golden Rules
The golden rules are divided into three groups:

Place Users in Control
Reduce Users’ Memory Load
Make the Interface Consistent

Each of these groups contains a number of specific rules. The rules (and a keyword for each rule) for each group are:

Place Users in Control

Use modes judiciously (modeless)
Allow users to use either the keyboard or mouse (flexible)
Allow users to change focus (interruptible)
Display descriptive messages and text(Helpful)
Provide immediate and reversible actions, and feedback (forgiving)
Provide meaningful paths and exits (navigable)
Accommodate users with different skill levels (accessible)
Make the user interface transparent (facilitative)
Allow users to customize the interface (preferences)
Allow users to directly manipulate interface objects (interactive)

Reduce Users’ Memory Load

Relieve short-term memory (remember)
Rely on recognition, not recall (recognition)
Provide visual cues (inform)
Provide defaults, undo, and redo (forgiving)
Provide interface shortcuts (frequency)
Promote an object-action syntax (intuitive)
Use real-world metaphors (transfer)
User progressive disclosure (context)
Promote visual clarity (organize)

Make the Interface Consistent

Sustain the context of users’ tasks (continuity)
Maintain consistency within and across products (experience)
Keep interaction results the same (expectations)
Provide aesthetic appeal and integrity (attitude)
Encourage exploration (predictable)

Q2 a) Elaborate COCOMO model for Cost estimation.

Add answer here : https://www.doubtly.in/q/elaborate-cocomo-model-cost-estimation/

Q2 b) Illustrate the SCM process.

It uses the tools which keep that the necessary change has been implemented adequately to the appropriate component. The SCM process defines a number of tasks:

Identification of objects in the software configuration
Version Control
Change Control
Configuration Audit
Status Reporting

Processes involved in SCM – Configuration management provides a disciplined environment for smooth control of work products. It involves the following activities:

Identification and Establishment – Identifying the configuration items from products that compose baselines at given points in time (a baseline is a set of mutually consistent Configuration Items, which has been formally reviewed and agreed upon, and serves as the basis of further development). Establishing relationships among items, creating a mechanism to manage multiple levels of control and procedure for the change management system.
Version control – Creating versions/specifications of the existing product to build new products with the help of the SCM system. A description of the version is given below:Suppose after some changes, the version of the configuration object changes from 1.0 to 1.1. Minor corrections and changes result in versions 1.1.1 and 1.1.2, which is followed by a major update that is object 1.2. The development of object 1.0 continues through 1.3 and 1.4, but finally, a noteworthy change to the object results in a new evolutionary path, version 2.0. Both versions are currently supported.
Change control – Controlling changes to Configuration items (CI). The change control process is explained in Figure below:A change request (CR) is submitted and evaluated to assess technical merit, potential side effects, the overall impact on other configuration objects and system functions, and the projected cost of the change. The results of the evaluation are presented as a change report, which is used by a change control board (CCB) —a person or group who makes a final decision on the status and priority of the change. An engineering change Request (ECR) is generated for each approved change. Also, CCB notifies the developer in case the change is rejected with proper reason. The ECR describes the change to be made, the constraints that must be respected, and the criteria for review and audit. The object to be changed is “checked out” of the project database, the change is made, and then the object is tested again. The object is then “checked in” to the database and appropriate version control mechanisms are used to create the next version of the software.
Configuration auditing – A software configuration audit complements the formal technical review of the process and product. It focuses on the technical correctness of the configuration object that has been modified. The audit confirms the completeness, correctness, and consistency of items in the SCM system and tracks action items from the audit to closure.
Reporting – Providing accurate status and current configuration data to developers, testers, end users, customers, and stakeholders through admin guides, user guides, FAQs, Release notes, Memos, Installation Guide, Configuration guides, etc.

Importance of Software Configuration Management

Effective Bug Tracking: Linking code modifications to issues that have been reported, makes bug tracking more effective.
Continuous Deployment and Integration: SCM combines with continuous processes to automate deployment and testing, resulting in more dependable and timely software delivery.
Risk management: SCM lowers the chance of introducing critical flaws by assisting in the early detection and correction of problems.
Support for Big Projects: Source Code Control (SCM) offers an orderly method to handle code modifications for big projects, fostering a well-organized development process.
Reproducibility: By recording precise versions of code, libraries, and dependencies, source code versioning (SCM) makes builds repeatable.
Parallel Development: SCM facilitates parallel development by enabling several developers to collaborate on various branches at once.

Q3 a) Describe the waterfall model and evolutionary process model.

answer : https://www.doubtly.in/q/describe-waterfall-model-evolutionary-process-model/

Q3 b) What is Risk management? Discuss Common sources of risk in IT projects.

Risk management is the process of identifying, assessing, prioritizing, and mitigating risks that could potentially impact the success of a project or an organization.

Steps in Risk Management:

Risk Identification:
- This step involves identifying potential risks that could arise during the course of the project. Risks can come from various sources such as technical, organizational, external, or environmental factors.
- Techniques like brainstorming, checklists, interviews, and documentation review are commonly used to identify risks.
Risk Analysis:
- Once risks are identified, they need to be analyzed to determine their potential impact and likelihood of occurrence. This step helps in understanding the severity of each risk and prioritizing them for further action.
- Risk analysis involves assessing the consequences of risks if they occur and the probability of their occurrence.
Risk Planning:
- After analyzing risks, a plan is developed to mitigate, avoid, transfer, or accept them. Risk planning involves developing strategies and action plans to address identified risks.
- Strategies could include risk avoidance (eliminating the risk altogether), risk mitigation (reducing the impact or likelihood of the risk), risk transfer (shifting the risk to a third party, like insurance), or risk acceptance (accepting the consequences if the risk occurs).
Risk Monitoring:
- Risk management is an ongoing process throughout the project lifecycle. Risk monitoring involves tracking identified risks, assessing their status, and evaluating the effectiveness of risk mitigation strategies.
- It’s important to regularly review and update the risk management plan as new risks emerge or existing risks evolve.

Common Sources of Risk in IT Projects:

Technological Complexity:
- Complexity in technology can lead to technical challenges, delays, and increased costs if not managed properly.
Unclear Requirements:
- Incomplete or ambiguous requirements can lead to scope creep, rework, and project delays.
Resource Constraints:
- Limited availability of skilled resources, hardware, or software can impact project timelines and quality.
Integration Issues:
- Integration of different systems or components may pose compatibility issues, leading to system failures or performance issues.
Security Threats:
- Cybersecurity threats such as data breaches, malware attacks, or unauthorized access can compromise the confidentiality, integrity, and availability of IT systems and data.
Vendor or Supplier Risks:
- Dependence on third-party vendors or suppliers for software, hardware, or services can introduce risks related to vendor reliability, delivery delays, or quality issues.
Regulatory Compliance:
- Non-compliance with industry regulations or legal requirements can result in penalties, legal disputes, and reputational damage.
Change Management:
- Resistance to change within the organization or among stakeholders can hinder project implementation and adoption.
Budget and Schedule Constraints:
- Budget overruns or schedule delays can occur due to poor estimation, scope changes, or unexpected events.
External Factors:
- External factors such as economic conditions, geopolitical events, natural disasters, or pandemics can impact project execution and delivery timelines.

Q4. a) What are the different phases in project life cycle with suitable examples?

The project life cycle refers to the series of phases that a project goes through from initiation to completion. Each phase represents a distinct stage in the project where specific tasks, deliverables, and objectives are accomplished. the phases in a project life cycle along with suitable examples:

Initiation Phase:
- This is the first phase of the project life cycle where the project is conceived, authorized, and defined.
- Example: Imagine a company wants to develop a new mobile application. In the initiation phase, the project stakeholders define the project’s purpose, scope, objectives, and initial budget.
Planning Phase:
- In this phase, detailed planning is carried out to define project scope, objectives, deliverables, resources, schedule, and budget.
- Example: Continuing with the mobile application project, in the planning phase, the project team creates a project plan outlining tasks, milestones, dependencies, and resource allocation. They also conduct risk analysis and develop a communication plan.
Execution Phase:
- This phase involves executing the project plan, coordinating resources, and completing project deliverables as outlined in the plan.
- Example: For the mobile application project, the execution phase involves actual development activities like coding, designing user interfaces, implementing features, and conducting testing.
Controlling Phase:
- During this phase, project performance is monitored, and project activities are controlled to ensure that the project stays on track in terms of scope, schedule, budget, and quality.
- Example: In the mobile application project, the project manager monitors progress against the project plan, tracks budget expenditure, manages risks, and resolves issues as they arise. They may also conduct regular meetings to review project status.
Closing Phase:
- This is the final phase of the project life cycle where the project is formally completed, and project closure activities are conducted.
- Example: After the mobile application is developed, tested, and deployed to users, the closing phase involves activities such as obtaining client acceptance, documenting lessons learned, releasing project resources, and handing over deliverables to the operations team.

Q4 b) What are the Agile Methodologies? Explain any of them.

answer: https://www.doubtly.in/q/agile-methodologies-explain/

Q5. a) Develop the SRS of University Management system.

src : https://www.doubtly.in/q/develop-srs-university-management-system/

Q5 b) Describe the details of FTR and Walkthrough.

FTR (Formal Technical Review) and Walkthrough are both methods used in software engineering for inspecting and reviewing software artifacts, such as requirements documents, design specifications, or code. Let’s break down each one:

Formal Technical Review (FTR):

Purpose: FTR aims to identify defects and issues in software artifacts early in the development process.
Participants: Typically involves a formal group of reviewers, including developers, testers, project managers, and sometimes users or stakeholders.
Process:
- Preparation: Before the review meeting, the artifact to be reviewed is distributed to all participants. Reviewers examine the artifact thoroughly, noting any defects, ambiguities, or inconsistencies.
- Meeting: In a structured meeting, the reviewers discuss their findings and document them. Discussions may involve clarifying requirements, questioning design decisions, or pointing out potential problems.
- Follow-up: After the meeting, the author of the artifact addresses the identified issues, making corrections or modifications as necessary.
Documentation: The results of the review, including identified issues and actions taken, are documented for future reference.

Walkthrough:

Purpose: Walkthroughs are more informal compared to FTR and are primarily aimed at familiarizing team members with the content of a document or code.
Participants: Typically involves the author of the artifact and a small group of peers or stakeholders.
Process:
- Presenter: The author presents the artifact, walking through its content, explaining its purpose, structure, and key points.
- Discussion: Participants can ask questions, seek clarification, or provide feedback during the walkthrough. This interaction helps in ensuring everyone understands the artifact and can provide valuable insights.
- Note-taking: Notes may be taken during the walkthrough to capture feedback, questions, and suggestions.
Follow-up: After the walkthrough, the author may revise the artifact based on the feedback received.

Key Differences:

Formality: FTR is more formal, structured, and involves a larger group of reviewers. Walkthroughs are less formal and typically involve a smaller group.
Purpose: FTR focuses on identifying defects and improving quality, while walkthroughs are more about understanding and gathering feedback.
Depth of Review: FTR involves a thorough examination of the artifact for defects and issues, while walkthroughs are more focused on understanding the content and gathering initial impressions.

Here is an comparision between both : https://www.doubtly.in/q/compare-ftr-walkthrough-sepm/

Q6. a) Explain project scheduling and describe CPM and PERT.

Project scheduling is the process of determining start and end dates for project activities, allocating resources, and establishing dependencies among tasks to achieve project objectives within defined constraints such as time, cost, and resources. Effective scheduling helps in organizing and managing project activities, optimizing resource utilization, and ensuring timely project completion.

Two widely used methods for project scheduling are Critical Path Method (CPM) and Program Evaluation and Review Technique (PERT).

Critical Path Method (CPM):

Definition: CPM is a deterministic scheduling technique used to determine the longest sequence of dependent activities (critical path) in a project, which dictates the minimum duration required to complete the project.
Key Features:
1. Activity-Based: Breaks down the project into a network of activities and their dependencies.
2. Deterministic: Relies on known activity durations and dependencies to calculate project duration.
3. Focus on Critical Path: Identifies the sequence of activities that collectively determine the shortest project duration.
4. Float Analysis: Identifies non-critical paths and activities with slack or float time, which can be delayed without impacting project completion.
Steps:
1. Identify project activities and their dependencies.
2. Estimate activity durations.
3. Construct a network diagram (Activity-on-Node or Activity-on-Arrow).
4. Calculate earliest start and finish times, and latest start and finish times for each activity.
5. Identify the critical path (activities with zero float) and total project duration.

Program Evaluation and Review Technique (PERT):

Definition: PERT is a probabilistic scheduling technique used to analyze and represent the uncertainty in project duration by considering three time estimates for each activity: optimistic (O), most likely (M), and pessimistic (P).
Key Features:
1. Probabilistic Approach: Incorporates uncertainty by using three time estimates for each activity.
2. Activity Duration Calculation: Calculates activity durations using weighted averages of the three time estimates (PERT formula).
3. Focus on Variability: Identifies activities with the highest variability and potential impact on project duration.
4. Probability Analysis: Estimates the probability of completing the project within a specified duration.
Steps:
1. Identify project activities and their dependencies.
2. Determine optimistic (O), most likely (M), and pessimistic (P) time estimates for each activity.
3. Calculate activity durations using the PERT formula: (O + 4M + P) / 6.
4. Construct a network diagram (similar to CPM).
5. Perform forward and backward pass calculations to determine earliest start and finish times, latest start and finish times, and float.
6. Analyze the critical path and project duration uncertainty.

Q6 b) Explain software reverse engineering in detail.

Answer : https://www.doubtly.in/q/explain-software-reverse-engineering-detail/

references :

https://www.geeksforgeeks.org/software-engineering-system-configuration-management

Table of Contents