Software Jun
Software Jun
Software Jun
A good and effective requirements engineering tool needs to incorporate the best
practices of requirements definition and management.
The requirements Engineering approach should be highly iterative with the goal of
establishing managed and effective communication and collaboration.
Thus, a CASE tool must have the following features from the requirements
engineering viewpoint:
a dynamic, rich editing environment for team members to capture and manage
requirements
to create a centralised repository
to create task-driven workflow to do change management, and defect tracking.
But, what is a good process of Requirements Engineering for the CASE?
Requirement Elicitation
A simple technique for requirements elicitation is to ask “WHY”.
CASE tools support a dynamic, yet intuitive, requirements capture and management
environment that supports content and its editing. Some of the features available for
requirement elicitation are:
Reusable requirements and design templates for various types of system
Keeping track of important system attributes like performance and security
It may also support a common vocabulary of user-defined terms that can be
automatically highlighted to be part of glossary.
Provide feature for the assessment of the quality of requirements
Separate glossary for ambiguous terms that can be flagged for additional
clarification.
Risk Pending: According to the priority, low priority risks are pushed at the end
of the queue with a view of various resources (hardware, man power, software)
and in case it takes more time their priority is made higher.
Risk Resolution: Risk manager makes a strong resolve how to solve the risk.
Risk elimination: This action leads to serious error in software.
Risk transfer: If the risk is transferred to some part of the module, then risk
analysis table entries get modified. Thereby, again risk manager will control high
priority risk.
Disclosures: Announce the risk of less priority to the customer or display
message box as a warning. And thereby the risk is left out to the user, such that he
should take proper steps during data entry, etc.
Risk not solvable: If a risk takes more time and more resources, then it is dealt in
its totality in the business aspect of the organisation and thereby it is notified to
the customer, and the team member proposes an alternate solution. There is a
slight variation in the customer specification after consultation.
RISK RECOVERY
Full : The risk analysis table is scanned and if the risk is fully solved, then
corresponding entry is deleted from the table.
Partial : The risk analysis table is scanned and due to partially solved risks, the
entries in the table are updated and thereby priorities are also updated.
Extra/alternate features : Sometimes it is difficult to remove some risks, and in that
case, we can add a few extra features, which solves the problem. Therefore, a bit of
coding is done to get away from the risk. This is later documented or notified to the
customer.
What is the significance of Software Engineering? Discuss Spiral Model. Explain the types of
projects for whom spiral model is suitable.
What do you mean by Scheduling of a Software Project ? Explain any two types of
scheduling techniques used in Software Engineering
Explain different phases of Waterfall Model. What are its advantages and disadvantages?
It is the simplest, oldest and most widely used process model. In this model, each phase of
the life cycle is completed before the start of a new phase. It is actually the first engineering
approach of software development.
The functions of various phases are discussed in software process technology.
The waterfall model provides a systematic and sequential approach to software
development and is better than the build and fix approach. But, in this model,
complete requirements should be available at the time of commencement of the
project, but in actual practice, the requirements keep on originating during different
phases. The water fall model can accommodate the new requirements only in
maintenance phase. Moreover, it does not incorporate any kind of risk assessment. In
waterfall model, a working model of software is not available. Thus, there is no
methods to judge the problems of software in between different phases.
A slight modification of the waterfall model is a model with feedback. Once software
is developed and is operational, then the feedback to various phases may be given.
What is meant by Prototyping? What are the types of projects where prototype is
developed? What are the pros and cons of a prototype?
Prototyping is defined as the process of developing a working replication of a product or
system that has to be engineered. It offers a small scale facsimile of the end product and is
used for obtaining customer feedback as described below:
The Prototyping Model is one of the most popularly used Software Development Life Cycle
Models (SDLC models). This model is used when the customers do not know the exact
project requirements beforehand. In this model, a prototype of the end product is first
developed, tested and refined as per customer feedback repeatedly till a final acceptable
prototype is achieved which forms the basis for developing the final product.
Advantages –
The customers get to see the partial product early in the life cycle. This ensures a
greater level of customer satisfaction and comfort.
New requirements can be easily accommodated as there is scope for refinement.
Missing functionalities can be easily figured out.
Errors can be detected much earlier thereby saving a lot of effort and cost, besides
enhancing the quality of the software.
The developed prototype can be reused by the developer for more complicated
projects in the future.
Flexibility in design.
Disadvantages –
Costly w.r.t time as well as money.
There may be too much variation in requirements each time the prototype is
evaluated by the customer.
Poor Documentation due to continuously changing customer requirements.
It is very difficult for developers to accommodate all the changes demanded by the
customer.
There is uncertainty in determining the number of iterations that would be required
before the prototype is finally accepted by the customer.
After seeing an early prototype, the customers sometimes demand the actual product
to be delivered soon.
Developers in a hurry to build prototypes may end up with sub-optimal solutions.
The customer might lose interest in the product if he/she is not satisfied with the
initial prototype.
Version control is the management of multiple revisions of the same unit of item during the
software development process. For example, a system requirement specification (SRS) is
produced after taking into account the user requirements which change with time into
account. Once a SRS is finalized, documented and approved, it is given a document number,
with a unique identification number. The name of the items may follow a hierarchical
pattern which may consist of the following: Project identifier Configuration item (or
simply item, e.g. SRS, program, data model) Change number or version number The
identification of the configuration item must be able to provide the relationship between
items whenever such relationship exists. The identification process should be such that it
uniquely identifies the configuration item throughout the development life cycle, such that
all such changes are traceable to the previous configuration. An evolutionary graph
graphically reflects the history of all such changes. The aim of these controls is to facilitate
the return to any previous state of configuration item in case of any unresolved issue in the
current unapproved version.
The above evolutionary graph(Figure 4.4) depicts the evolution of a configuration item
during the development life cycle. The initial version of the item is given version number Ver
1.0. Subsequent changes to the item which could be mostly fixing bugs or adding minor
functionality is given as Ver 1.1 and Ver 1.2. After that, a major modification to Ver 1.2 is
given a number Ver 2.0 at the same time, a parallel version of the same item without the
major modification is maintained and given a version number 1.3.
Commercial tools are available for version control which performs one or more of following
tasks; Source code control Revision control Concurrent version control
Let us consider the following simple HTML file in a web based application
(welcome.htm)
<html>
<head>
<Title> A simple HTML Page</title>
</head>
<body>
<h1> Welcome to HTML Concepts</h1>
</body>
</html>
The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) (also called a requirements document). This report lays
a foundation for software engineering activities and is constructing when entire
requirements are elicited and analyzed. SRS is a formal report, which acts as a
representation of software that enables the customers to review whether it (SRS) is
according to their requirements. Also, it comprises user requirements for a system as well as
detailed specifications of the system requirements.
The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment. It serves several goals depending on
who is writing it. First, the SRS could be written by the client of a system. Second, the SRS
could be written by a developer of the system. The two methods create entirely various
situations and establish different purposes for the document altogether. The first case, SRS,
is used to define the needs and expectation of the users. The second case, SRS, is written for
various purposes and serves as a contract document between customer and developer.
2. On site observation: In case of real life systems, the actual site visit is performed
to get a close look of system. It helps the analyst to detect the problems of existing
system.
What is Change Management ? Explain the process of making a change request with the
help of diagram.
A formal process of change management is acutely felt in the current scenario when the
software is developed in a very complex distributed environment with many versions of a
software existing at the same time, many developers involved in the development process
using different technologies. The ultimate bottomline is to maintain the integrity of the
software product while incorporating changes. The following are the objectives of software
change management process:
1. Configuration identification: The source code, documents, test plans, etc. The process of
identification involves identifying each component name, giving them a version name (a
unique number for identification) and a configuration identification.
2. Configuration control: Cntrolling changes to a product. Controlling release of a product
and changes that ensure that the software is consistent on the basis of a baseline product.
3. Review: Reviewing the process to ensure consistency among different configuration
items.
4. Status accounting : Recording and reporting the changes and status of the components.
5. Auditing and reporting: Validating the product and maintaining consistency of the product
throughout the software life cycle.
Process of changes: As we have discussed, baseline forms the reference for any change.
Whenever a change is identified, the baseline which is available in project database is
copied by the change agent (the software developer) to his private area. Once the
modification is underway the baseline is locked for any further modification which may lead
to inconsistency. The records of all changes are tracked and recorded in a status accounting
file. After the changes are completed and the changes go through a change control
procedure, it becomes a approved item for updating the original baseline in the project
database
What are various methods for constructing the cost of a project ? Explain any one of the
methods with an example.
Cost estimation is the next step for projects. The cost of a project is derived not only from
the estimates of effort and size but from other parameters such as hardware, travel
expenses, telecommunication costs, training cost etc. should also be taken into account.
Explain various levels of SEI-LMM.
The Capability Maturity Model (CMM) is a procedure used to develop and refine an
organization's software development process.
The model defines a five-level evolutionary stage of increasingly organized and consistently
more mature processes.
CMM was developed and is promoted by the Software Engineering Institute (SEI), a research
and development center promote by the U.S. Department of Defense (DOD).
Capability Maturity Model is used as a benchmark to measure the maturity of an
organization's software process.
Level 1: Initial
Ad hoc activities characterize a software development organization at this level. Very few or
no processes are described and followed. Since software production processes are not
limited, different engineers follow their process and as a result, development efforts
become chaotic. Therefore, it is also called a chaotic level.
Level 2: Repeatable
At this level, the fundamental project management practices like tracking cost and schedule
are established. Size and cost estimation methods, like function point analysis, COCOMO,
etc. are used.
Level 3: Defined
At this level, the methods for both management and development activities are defined and
documented. There is a common organization-wide understanding of operations, roles, and
responsibilities. The ways through defined, the process and product qualities are not
measured. ISO 9000 goals at achieving this level.
Level 4: Managed
At this level, the focus is on software metrics. Two kinds of metrics are composed.
Product metrics measure the features of the product being developed, such as its size,
reliability, time complexity, understandability, etc.
Process metrics follow the effectiveness of the process being used, such as average defect
correction time, productivity, the average number of defects found per hour inspection, the
average number of failures detected during testing per LOC, etc. The software process and
product quality are measured, and quantitative quality requirements for the product are
met. Various tools like Pareto charts, fishbone diagrams, etc. are used to measure the
product and process quality. The process metrics are used to analyze if a project performed
satisfactorily. Thus, the outcome of process measurements is used to calculate project
performance rather than improve the process.
Level 5: Optimizing
At this phase, process and product metrics are collected. Process and product measurement
data are evaluated for continuous process improvement.
Define the term “Software Quality”. List various factors that will affect software quality.
Software quality product is defined in term of its fitness of purpose. That is, a quality
product does precisely what the users want it to do. For software products, the fitness of
use is generally explained in terms of satisfaction of the requirements laid down in the SRS
document. Although "fitness of purpose" is a satisfactory interpretation of quality for many
devices such as a car, a table fan, a grinding machine, etc.for software products, "fitness of
purpose" is not a wholly satisfactory definition of quality.
Example: Consider a functionally correct software product. That is, it performs all tasks as
specified in the SRS document. But, has an almost unusable user interface. Even though it
may be functionally right, we cannot consider it to be a quality product.
Correctness
These requirements deal with the correctness of the output of the software system. They
include −
Output mission
The required accuracy of output that can be negatively affected by inaccurate data or
inaccurate calculations.
The completeness of the output information, which can be affected by incomplete
data.
The up-to-dateness of the information defined as the time between the event and
the response by the software system.
The availability of the information.
The standards for coding and documenting the software system.
Reliability
Reliability requirements deal with service failure. They determine the maximum allowed
failure rate of the software system, and can refer to the entire system or to one or more of
its separate functions.
Efficiency
It deals with the hardware resources needed to perform the different functions of the
software system. It includes processing capabilities (given in MHz), its storage capacity
(given in MB or GB) and the data communication capability (given in MBPS or GBPS).
It also deals with the time between recharging of the system’s portable units, such as,
information system units located in portable computers, or meteorological units placed
outdoors.
Integrity
This factor deals with the software system security, that is, to prevent access to
unauthorized persons, also to distinguish between the group of people to be given read as
well as write permit.
Usability
Usability requirements deal with the staff resources needed to train a new employee and to
operate the software system.
Product Revision Quality Factors
According to McCall’s model, three software quality factors are included in the product
revision category. These factors are as follows −
Maintainability
This factor considers the efforts that will be needed by users and maintenance personnel to
identify the reasons for software failures, to correct the failures, and to verify the success of
the corrections.
Flexibility
This factor deals with the capabilities and efforts required to support adaptive maintenance
activities of the software. These include adapting the current software to additional
circumstances and customers without changing the software. This factor’s requirements
also support perfective maintenance activities, such as changes and additions to the
software in order to improve its service and to adapt it to changes in the firm’s technical or
commercial environment.
Testability
Testability requirements deal with the testing of the software system as well as with its
operation. It includes predefined intermediate results, log files, and also the automatic
diagnostics performed by the software system prior to starting the system, to find out
whether all components of the system are in working order and to obtain a report about the
detected faults. Another type of these requirements deals with automatic diagnostic checks
applied by the maintenance technicians to detect the causes of software failures.
Product Transition Software Quality Factor
According to McCall’s model, three software quality factors are included in the product
transition category that deals with the adaptation of software to other environments and its
interaction with other software systems. These factors are as follows −
Portability
Portability requirements tend to the adaptation of a software system to other environments
consisting of different hardware, different operating systems, and so forth. The software
should be possible to continue using the same basic software in diverse situations.
Reusability
This factor deals with the use of software modules originally designed for one project in a
new software project currently being developed. They may also enable future projects to
make use of a given module or a group of modules of the currently developed software. The
reuse of software is expected to save development resources, shorten the development
period, and provide higher quality modules.
Interoperability
Interoperability requirements focus on creating interfaces with other software systems or
with other equipment firmware. For example, the firmware of the production machinery
and testing equipment interfaces with the production control software.
Previous Page