ASE Question Bank Answer
ASE Question Bank Answer
SDLC (Software Development Life Cycle) is a structured process that outlines the steps
involved in the development of software. The objective of SDLC is to produce high-quality
software that meets customer expectations and is delivered on time and within budget. It
consists of the following phases:
• Requirement Gathering and Analysis: This is the most crucial stage, where
developers gather and analyze user requirements to understand what the client expects
from the software.
• System Design: In this phase, developers create the architecture of the system based
on the requirements. It involves designing both the high-level system components and
the low-level details.
• Implementation (Coding): Once the design is ready, the actual coding of the
software takes place. Developers write the source code in this phase.
• Testing: The system is tested to find defects and ensure that it meets the user
requirements. Various testing methods, like unit testing, integration testing, and
system testing, are conducted.
• Deployment: The software is deployed into the production environment, making it
available for the end users.
• Maintenance: After deployment, the software may need modifications or
improvements to correct issues or adapt to new requirements over time.
Software has unique characteristics that distinguish it from other engineering products:
• Intangibility: Software does not have a physical form. Unlike hardware, you cannot
touch software—it is a collection of programs and procedures.
• Correctness: Software must meet the requirements and perform the tasks it was
intended for without any errors.
• Flexibility: One of the major advantages of software is its flexibility. It can be easily
modified or enhanced over time to accommodate new requirements, fix bugs, or
improve performance.
• Maintainability: Software needs to be maintained over time to fix bugs, improve
performance, and add new features. A well-designed software system is easy to
maintain and extend.
• Reusability: Parts of software, such as functions, libraries, or entire modules, can
often be reused in other projects, improving efficiency.
• Portability: Software should be able to operate on different platforms or
environments without significant modification.
1. Intangibility: Unlike physical products, software cannot be seen or touched. Its value
lies in the functionality it provides, not in any physical form.
2. Dependability: Software as a product must be dependable, meaning it should
function consistently without failure, especially in critical applications such as
banking, healthcare, or transportation systems.
6. What is the prototyping technique? How are prototype models prepared for
a software process? Discuss.
The prototyping technique is a software development method where a prototype (an early
working version of the system) is built, demonstrated to the users, and refined based on
feedback. This iterative process helps in better understanding the user's requirements and
refining them over time.
1. System Software: This software manages and controls the hardware components of a
computer system. Examples include operating systems (Windows, macOS) and
device drivers.
2. Application Software: Software designed to perform specific tasks for end users,
such as word processors, spreadsheets, and web browsers (e.g., Microsoft Word,
Excel, Google Chrome).
3. Embedded Software: Software designed for specific devices that are not generally
considered computers, such as the software that runs in a microwave oven, washing
machine, or an automobile's braking system.
4. Web-Based Software: These are applications that run on web browsers and are
accessed through the internet (e.g., Google Docs, Gmail).
10. Explain function and non-function oriented design. Explain the objective
of software design.
• Importance:
o Ensures that all the requirements are captured accurately and
comprehensively.
o Helps in prioritizing requirements based on user needs and business impact.
o Reduces the chances of costly revisions later in the project.
SRS (Software Requirements Specification) is a detailed document that outlines all the
functional and non-functional requirements of a software system. It serves as a contract
between the developers and the stakeholders, ensuring that both parties are aligned on what
the system should do.
• Clarity: A good SRS provides clear and unambiguous requirements, reducing the
chances of miscommunication.
• Feasibility: It helps in assessing whether the project can be developed with the
available resources and technologies.
• Basis for design and development: The SRS acts as a blueprint for the design,
development, and testing phases.
• Foundation for testing: The requirements outlined in the SRS serve as the basis for
creating test cases and validating the final system.
• Change management: It makes it easier to manage scope changes by providing a
clear reference for the original requirements.
UML (Unified Modeling Language) is used to visualize the design of a system. It provides
a standard way to create blueprints for software development.
• Class Diagram: Describes the static structure of a system by showing its classes,
attributes, methods, and relationships.
• Use Case Diagram: Shows the interactions between users (actors) and the system,
focusing on what the system will do.
• Sequence Diagram: Illustrates how objects interact with each other over time. It
shows the sequence of messages exchanged between objects.
• Activity Diagram: Represents the flow of activities within a system, used to model
workflows or business processes.
• State Diagram: Describes the states that an object can be in and how it transitions
from one state to another in response to events.
• Component Diagram: Depicts the organization and dependencies of software
components.
• Deployment Diagram: Models the physical deployment of artifacts (software) on
hardware nodes, showing how the system will be executed in the real world.
14. Design activity diagrams for library management system and withdraw
money from bank ATM.
1. Insert card.
2. Enter PIN.
3. Select withdrawal option.
4. Enter amount.
5. Confirm transaction.
6. Dispense cash.
7. Retrieve card and receipt.
15. What is module cohesion and module coupling? Describe various types of
cohesion and coupling with suitable diagrams. Explain the importance of
maximizing cohesion and minimizing coupling.
• Module Cohesion: Refers to how closely related the functions within a single module
are. High cohesion is desirable because it makes the module easier to maintain and
understand. Types of cohesion:
o Functional Cohesion: All elements contribute to a single, well-defined task.
o Sequential Cohesion: One module’s output is another module’s input.
o Communicational Cohesion: All functions in a module operate on the same
data set.
• Module Coupling: Refers to the degree of dependency between two modules. Lower
coupling is preferred as it promotes modularity and independence. Types of coupling:
o Data Coupling: Modules share only the necessary data.
o Control Coupling: One module controls the behavior of another by passing
control flags.
o Common Coupling: Modules share global data (undesirable).
Importance: Maximizing cohesion within a module makes it more robust, readable, and
easier to maintain. Minimizing coupling between modules ensures that changes in one
module have minimal impact on others, enhancing modularity and making the system easier
to test and scale.
16. What is risk management? Explain the risk management process.
1. Risk Identification: Identifying potential risks that could affect the project.
2. Risk Analysis: Assessing the likelihood and impact of each risk.
3. Risk Prioritization: Ranking the risks based on their severity and likelihood.
4. Risk Mitigation: Developing strategies to reduce or eliminate the impact of risks.
5. Risk Monitoring: Continuously tracking risks and ensuring mitigation strategies are
effective throughout the project lifecycle.
17. Explain use case diagram. Draw a use case diagram for the Airlines
Management System.
A use case diagram models the interactions between actors (users) and the system. It
captures the functional requirements by showing what the system does without specifying
how it does it.