Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Software Jun

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 17

How do CASE tools help in effective Requirements Engineering ? Explain.

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.

What do we expect from the tool?


 It should have rich support for documentation that is easily understandable to
stakeholders and development teams.
 It should have the capability of tracking of requirements during various SDLC
systems.
 It should help in the development of standard technical and business
terminology for end clients.

Software Analysis and Specification


One of the major reasons of documenting requirements is to remove the ambiguity of
information. A good requirement specification is testable for each requirement.
One of the major features supported by CASE tools for specification is that the design
and implementation should be traceable to requirements. A good way to do so is to
support a label or a tag to the requirements. In addition it should have the following
features:
 Must have features for storing and documenting of requirements.
 Enable creation of models that are critical to the development of functional
requirements.
 Allow development of test cases that enable the verification of requirements and
their associated dependencies.
 Test cases help in troubleshooting the correlation between business
requirements and existing system constraints.

What do we expect from the tool?


 It should allow development of a labeled requirements document that helps in
traceability of requirements.
 It should allow both functional and non-functional requirements with related
quality attributes to be made.
 We should be able to develop the associated models.

Validation of Requirements Case Tools


A very important feature in this regard is to allow collaboration yet customizable
workflows for the software development team members. Also facilitating approvals
and electronic signatures to facilitate audit trails. Assigning owner of requirement may
be helpful if any quality attributes may need changes. Thus, a prioritised validated
documented and approved requirements can be obtained.
Managing Requirements
The requirements document should have visibility and help in controlling the software
delivery process. Some such features available in CASE tools are:
 estimation of efforts and cost
 specification of project schedule such as deadline, staff requirements and other
constraints
 specification of quality parameters.
Software Change Management
An incomplete or ambiguous requirement if detected early in the analysis phase can
be changed easily with minimum cost. However, once they are converted to baselines
after requirements validations the change should be controlled.
One of the major requirements of change management is:
Any change to these requirements should follow a process which is defined as the
ability to track software requirements and their associated models/documents, etc.
(e.g., designs, DFDs and ERDs, etc.). This helps in determining the components that
will be impacted due to change. This also helps tracking and managing change. The
whole process starts with labeling the requirements properly.
Most CASE Tools store requirement baselines, including type, status, priority and
change history of a software item. Such traceability may be bi-directional in nature.
Static word processing documents or spreadsheet recedes communication issues
because those tools do not allow sharing and collaboration on up-to-date
requirements. To overcome this a CASE enabled requirements management
infrastructure offers the familiarity of environments such as Microsoft Word, with
added communication methods, such as email. Thus, CASE is a very useful tool for
requirement engineering.

Draw and explain the Risk Manager tool.


A priority is given to risk and the highest priority risk is handled first. Various factors
of the risk are who are the involved team members, what hardware and software items
are needed, where, when and why are resolved during risk management. The risk
manager does scheduling of risks. Risk management can be further categorised as
follows:
1. Risk Avoidance
a. Risk anticipation
b. Risk tools
2. Risk Detection
a. Risk analysis
b. Risk category
c. Risk prioritisation
3. Risk Control
a. Risk pending
b. Risk resolution
c. Risk not solvable
4. Risk Recovery
a. Full
b. Partial
c. Extra/alternate features
2.4.2 Risk Avoidance
Risk Anticipation: Various risk anticipation rules are listed according to standards
from previous projects’ experience, and also as mentioned by the project manager.
Risk tools: Risk tools are used to test whether the software is risk free. The tools have
built-in data base of available risk areas and can be updated depending upon the type
of project.

2.4.3 Risk Detection


The risk detection algorithm detects a risk and it can be categorically stated as :
Risk Analysis: In this phase, the risk is analyzed with various hardware and software
parameters as probabilistic occurrence (pr), weight factor (wf) (hardware resources,
lines of code, persons), risk exposure (pr * wf).

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.

The importance of Software engineering is as follows:

1. Reduces complexity: Big software is always complicated and challenging to progress.


Software engineering has a great solution to reduce the complication of any project.
Software engineering divides big problems into various small issues. And then start
solving each small issue one by one. All these small problems are solved
independently to each other.
2. To minimize software cost: Software needs a lot of hardwork and software engineers
are highly paid experts. A lot of manpower is required to develop software with a
large number of codes. But in software engineering, programmers project everything
and decrease all those things that are not needed. In turn, the cost for software
productions becomes less as compared to any software that does not use software
engineering method.
3. To decrease time: Anything that is not made according to the project always wastes
time. And if you are making great software, then you may need to run many codes to
get the definitive running code. This is a very time-consuming procedure, and if it is
not well handled, then this can take a lot of time. So if you are making your software
according to the software engineering method, then it will decrease a lot of time.
4. Handling big projects: Big projects are not done in a couple of days, and they need
lots of patience, planning, and management. And to invest six and seven months of
any company, it requires heaps of planning, direction, testing, and maintenance. No
one can say that he has given four months of a company to the task, and the project
is still in its first stage. Because the company has provided many resources to the
plan and it should be completed. So to handle a big project without any problem, the
company has to go for a software engineering method.
5. Reliable software: Software should be secure, means if you have delivered the
software, then it should work for at least its given time or subscription. And if any
bugs come in the software, the company is responsible for solving all these bugs.
Because in software engineering, testing and maintenance are given, so there is no
worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made according to the standards.
Software standards are the big target of companies to make it more effective. So
Software becomes more effective in the act with the help of software engineering.

What do you mean by Scheduling of a Software Project ? Explain any two types of
scheduling techniques used in Software Engineering

Project-task scheduling is a significant project planning activity. It comprises deciding which


functions would be taken up when. To schedule the project plan, a software project
manager wants to do the following:

1. Identify all the functions required to complete the project.


2. Break down large functions into small activities.
3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the
activities.
5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities that decide the
duration of the project.

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.

The sequential phases in Waterfall model are −


 Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
 System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
 Implementation − With inputs from the system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system
is tested for any faults and failures.
 Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment. To
fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the customer
environment

Some of the major advantages of the Waterfall Model are as follows −


 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

The major disadvantages of the Waterfall Model are as follows −


 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow identifying
any technological or business bottleneck or challenges early.

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.

What are the types of projects where prototype is developed search???

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.

1. Record review: A review of recorded documents of the organisation is


performed. Procedures, manuals, forms and books are reviewed to see format and
functions of present system. The search time in this technique is more.

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.

3. Interview: A personal interaction with staff is performed to identify their


requirements. It requires experience of arranging the interview, setting the stage,
avoiding arguments and evaluating the outcome.

4. Questionnaire: It is an effective tool which requires less effort and produces a


written document about requirements. It examines a large number of respondents
simultaneously and gets customized answers. It gives person sufficient time to
answer the queries and give correct answers.

In which phase of SDLC is SRS developed ? remaining

What is Change Management ? Explain the process of making a change request with the
help of diagram.

Change Management in software development refers to the transition from an existing


state of the software product to another improved state of the product. It controls,
supports, and manages changes to artifacts, such as code changes, process changes, or
documentation changes. Where CCP (Change Control Process) mainly identifies,
documents, and authorizes changes to a software application.
Each software development process follows Software Development Life Cycle
(SDLC) where each phase is accordingly followed to finally deliver a good quality software
product. Change Management does not come under any phases of SDLC still it has great
importance in the entire software development process. There are various types of change
management tools that are used for various purposes like to adopt, control, represent and
effect the change required. For example Change management tools for Flow Charting,
Project Planning, Data collection, etc.

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

You might also like