Que 1. What is Software Engineering?
Ans.: Software Engineering is the discipline that
aims to provide methods & procedures for developing software system.
It is the application of a systematic
disciplined & quantifiable approach of development & maintenance of
software. It includes different techniques & procedures of “Software
development process to improve the reliability of software”.
In other words, software Engineering is the
application of science & maths by which the capabilities of computer
equipments are made useful to man via computer programs.
Que 2. What is Software Development Life
Cycle?
OR
Explain in
detail the different stages of SDLC.
Ans.: It is a concept of providing a complete
support to a software product throughout all the stages of its evolution
The systems development life cycle (SDLC)
is a conceptual model used in project management that describes the stages
involved in an information system development project, from an initial feasibility
study to maintenance of the completed application.
The SDLC
Waterfall Model:
Small to medium
database software projects are generally broken down into six stages:
Here
the outputs from a specific stage serve as the initial inputs for the following
stage.
Planning Stage:
The planning stage
establishes a bird's eye view of the software product, and uses this to
establish the basic project structure. This stage is used to evaluate
feasibility and risks associated with the project, and describe appropriate
management and technical approaches.
The outputs of the project planning stage
are the configuration management plan, the quality assurance plan, and the
project plan and schedule.
Requirements Definition Stage:
The requirements gathering process takes as
its input the goals identified in the project plan. Each goal is refined into a
set of one or more requirements. These requirements define the major functions
of the application, operational data areas and reference data areas. Each of
these definitions is termed a Requirement. Requirements are identified by
unique requirement identifiers and contain a requirement title and textual
description.
These requirements are fully described in
the Requirements Document and the Requirements Traceability Matrix (RTM). The
requirements document contains complete description of each requirement,
including diagrams and references to external documents as necessary.
Note: detailed listings of database tables and fields are not
included in the requirements document.
The outputs of the requirements definition
stage include:
i) The requirements
document
ii) The RTM
iii) An updated
project plan.
Design Stage:
The design stage takes as its initial input
the requirements identified in the approved requirements document. Design
elements describe the desired software features in detail, and generally
include functional hierarchy diagrams, screen layout diagrams, tables of
business rules, business process diagrams, pseudo code, and a complete
entity-relationship diagram with a full data dictionary. These design elements
are intended to describe the software in sufficient detail so that the skilled
programmers may develop the software with minimal additional input.
The outputs of the design stage:
i) The design
document
ii) An updated RTM,
iii) Updated
project plan.
Development Stage:
Here for each design element, a set of one
or more software artefacts will be produced. Software artefacts include but are
not limited to menus, data management forms, data reporting formats, and
specialized procedures and functions. Appropriate test cases will be developed
for each set of functionally related software artefacts, and an online help
system will be developed to guide users in their interactions with the
software.
Diagram:
The outputs of the development stage include:
i) A fully functional set of software that
satisfies the requirements and design elements previously documented.
ii) An online help system that describes
the operation of the software.
iii) An implementation map that identifies
the primary code entry points for all major system functions.
iv) A test plan that describes the test
cases to be used to validate the correctness and completeness of the software.
v) An updated RTM.
vi) An updated project plan.
Integration & Test Stage:
During the integration and
test stage, the software artefacts, online help, and test data are migrated
from the development environment to a separate test environment. At this point,
all test cases are run to verify the correctness and completeness of the
software. Successful execution of the test module confirms a robust and
complete migration capability. During this stage, reference data is finalized
for production use and production users are identified and linked to their
appropriate roles. The final reference data (or links to reference data source
files) and production user lists are compiled into the Production Initiation
Plan.
The outputs of the integration and test
stage include:
i) An integrated
set of software.
ii) An online help
system.
iii)
An implementation map.
iv)
A production initiation plan that describes reference data and production
users.
v)
An acceptance plan which contains the final module of test cases.
vi)
An updated project plan.
Installation & Acceptance Stage:
During the installation and acceptance
stage, the software artefacts, online help, and initial production data are
loaded onto the production server, all test cases are run to verify the
correctness and completeness of the software. After customer personnel have
verified that the initial production data load is correct and the test suite
has been executed with satisfactory results, the customer formally accepts the
delivery of the software.
Diagram:
The primary outputs of the installation and
acceptance stage include:
i) A production
application.
ii) A completed
acceptance test suite.
iii)
A memorandum of customer acceptance of the software.
Que 3. Define prototyping model.
Ans.: The prototyping model begins with the
requirements gathering. The developer and the customer meet and define the
objectives for the software, identify the needs, etc. A ‘quick design’ is then
created. This design focuses on those aspects of the software that will be
visible to the customer. It then leads to the construction of a prototype. The
prototype is then checked by the customer and any modifications or changes that
are required are made to the prototype. Looping takes place in this process and
better versions of the prototype are created. These are continuously shown to
the user so that any new changes can be updated in the prototype. This process
continues till the user is satisfied with the system. Once a user is satisfied,
the prototype is converted to the actual system with all considerations for
quality and security.
The prototype is considered as the ‘first
system’. It is advantageous because both the customers and the developers get a
feel of the actual system. But there are certain problems with the prototyping
model too.
i) The prototype
is usually created without taking into consideration overall software quality.
ii) When the
customer sees a working model in the form of a prototype, and then is told that
the actual software is not created, the customer can get irritated.
iii) Since the
prototype is to be created quickly, the developer will use whatever choices he
has at that particular time e.g. he may not know a good programming language,
but later may learn. He then cannot change the whole system for the new
programming language). Thus the prototype may be created with less-than-ideal
choices.
Que 4. Write a short note on Knowledge
Engineering.
Ans.: Knowledge
Engineering (KE) refers to
the building, maintaining and development of knowledge-based systems. It has a
great deal in common with software engineering, and is related to many computer
science domains such as artificial intelligence, databases, data mining, expert
systems, decision support systems and geographic information systems. Knowledge
engineering is also related to mathematical logic and is structured according
to our understanding of how human reasoning and logic works.
Various activities of KE specific for the
development of a knowledge-based system are:
•
Assessment of the problem
• Development of a
knowledge-based system shell / structure
• Implementation
of the structured knowledge into knowledge –bases
• Acquisition and
structuring of the related information, knowledge and specific preferences
• Testing and
validation of the inserted knowledge
• Integration and
maintenance of the system
• Revision and
evaluation of the system
Knowledge Engineering Principles: - Since the mid – 1980s, knowledge engineers
have developed a number of principles, methods and tools that considerably
improved the process of knowledge acquisition and ordering. Some of the key
principles are summarized as follows:
• Knowledge engineers acknowledge that
there are different types of knowledge and that the right approach and
technique should be used for the knowledge required.
• Knowledge engineers acknowledge that
there are different types of experts and expertise, and therefore the methods
should be chosen appropriately.
• Knowledge engineers recognize that there
are different ways of representing knowledge, which can aid the acquisition,
validation and re-use of knowledge.
• Knowledge engineers recognize that there
are different ways of using knowledge, so that the acquisition process can be
guided by the project aims (goal-oriented).
• Knowledge engineers use structured
methods to increase the efficiency of the acquisition process.
Views of Knowledge Engineering: - There are two main views to knowledge engineering:
• Transfer View – This is the
traditional view. In this view, we apply conventional knowledge engineering
techniques to transfer human knowledge into artificial intelligence systems.
• Modelling View – This is the alternative view. In this view,
the knowledge engineer attempts to model the knowledge and problem solving
techniques of the domain expert into the artificial intelligent system.
Que 5. What is Software Requirement?
Ans.: In software engineering, requirements
analysis is used for determining the needs or conditions to meet for a new or
altered product, taking account of the possibly conflicting requirements of the
various stakeholders or users. Systematic requirements analysis is also known
as requirements engineering. It is sometimes referred loosely by names such as
requirements gathering, requirements capture, or requirements specification.
Requirements analysis is critical to the success of a development project.
Requirements must be actionable,
measurable, testable, related to identified business needs or opportunities,
and defined to a level of detail sufficient for system design.
Conceptually,
requirements analysis includes three types of activity:
• Eliciting Requirements: the task of communicating with customers
and users to determine what their requirements are. This is sometimes also
called requirements gathering.
• Analyzing Requirements: determining whether the stated requirements
are unclear, incomplete, ambiguous, or contradictory, and then resolving these
issues.
• Recording Requirements: Requirements may be documented in various
forms, such as natural-language documents, use cases, user stories, or process
specifications.
