SIKKIM MANIPAL UNIVERSITY SOFTWARE ENGINEERING SUBJECT CODE – MI0033 Assignment Set- 1 Q1. Quality and reliability are related concepts but are fundamentally different in a number of ways. Discuss them. Answer: One of the challenges of software quality is that "everyone feels they understand it. In addition to more software specific definitions given below, there are several applicable definitions of quality which are used in business. Software quality may be defined as conformance to explicitly stated functional and performance requirements, explicitly documented development standards and implicit characteristics that are expected of all professionally developed software. The three key points in this definition: 1. Software requirements are the foundations from which quality is measured. Lack of conformance to requirement is lack of quality. SANTOSH GOWDA.H Reg No.: 521075728 3rd semester, Disha institute of management and technology Mobile No.: 9986840143
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SIKKIM MANIPAL UNIVERSITY
SOFTWARE ENGINEERING
SUBJECT CODE – MI0033
Assignment Set- 1
Q1. Quality and reliability are related concepts but are fundamentally
different in a number of ways. Discuss them.
Answer:
One of the challenges of software quality is that "everyone feels they
understand it.
In addition to more software specific definitions given below, there are
several applicable definitions of quality which are used in business.
Software quality may be defined as conformance to explicitly stated
functional and performance requirements, explicitly documented development
standards and implicit characteristics that are expected of all professionally
developed software.
The three key points in this definition:
1. Software requirements are the foundations from which quality is
measured.
Lack of conformance to requirement is lack of quality.
2. Specified standards define a set of development criteria that guide the
management in software engineering.
If criteria are not followed lack of quality will usually result.
3. A set of implicit requirements often goes unmentioned, for example ease
of use, maintainability etc.
If software conforms to its explicit requirements but fails to meet implicit
requirements, software quality is suspected.
A definition in Steve McConnell's Code Complete divides software into
two pieces: internal and external quality characteristics. External quality
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITYcharacteristics are those parts of a product that face its users, where internal
quality characteristics are those that do not.[4]
Another definition by Dr. Tom De Marco says "a product's quality is a
function of how much it changes the world for the better. This can be interpreted
as meaning that user satisfaction is more important than anything in determining
software quality.
Another definition, coined by Gerald Weinberg in Quality Software
Management: Systems Thinking, is "Quality is value to some person." This
definition stresses that quality is inherently subjective - different people will
experience the quality of the same software very differently. One strength of this
definition is the questions it invites software teams to consider, such as "Who are
the people we want to value our software?" and "What will be valuable to them?"
Software product quality
Product quality
conformance to requirements or program specification; related to
Reliability
Scalability
Correctness
Completeness
Absence of bugs
Fault-tolerance
Extensibility
Maintainability
Documentation
The Consortium for IT Software Quality (CISQ) was launched in 2009 to
standardize the measurement of software product quality. The Consortium's goal
is to bring together industry executives from Global 2000 IT organizations,
system integrators, outsourcers, and package vendors to jointly address the
challenge of standardizing the measurement of IT software quality and to promote
a market-based ecosystem to support its deployment.
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITYattributes are mean time to failure, rate of failure occurrence, and availability of
the system. Similarly, an attribute of portability is the number of target-dependent
statements in a program.
A scheme that could be used for evaluating software quality factors is
given below. For every characteristic, there are a set of questions which are
relevant to that characteristic. Some type of scoring formula could be developed
based on the answers to these questions, from which a measurement of the
characteristic can be obtained.
Q.3. Discuss the CMM 5 Levels for Software Process.
Answer.
The Software Process:
In recent years, there has been a significant emphasis on “process
maturity”. The Software Engineering Institute (SEI) has developed a
comprehensive model predicated on a set of software engineering capabilities that
should be present as organizations reach different levels of process maturity. To
determine an organization’s current state of process maturity, the SEI uses an
assessment that results in a five point grading scheme. The grading scheme
determines compliance with a capability maturity model (CMM) [PAU93] that
defines key activities required at different levels of process maturity. The SEI
approach provides a measure of the global effectiveness of a company’s software
engineering practices, and establishes five process maturity levels that are defined
in the following manner:
Level 1: Initial – The Software process is characterized as ad hoc and
occasionally even chaotic. Few processes are defined, and success depends on
individual effort.
Level 2: Repeatable – Basic project management processes are established to
track cost, schedule, and functionality. The necessary process discipline is in
place to repeat earlier successes on projects with similar applications.
Level 3: Defined – The software process for both management and engineering
activities is documented, standardized, and integrated into an organized-wide SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITYsoftware process. All projects use a documented and approved version of the
organizations process for developing and supporting software. This level includes
all characteristic defined for level 2.
Level 4: Managed – Detailed measures of the software process and product
quality are collected. Both the software process and products are quantitatively
understood and controlled using detailed measures. This level includes all
characteristics defined for level 3.
Level 5: Optimizing – Continuous process improvement is enabled by
quantitative feedback from the process and from testing innovative ideas and
technologies. This level includes all characteristics defined for level 4. The five
levels defined by the SEI were derived as a consequence of evaluating responses
to the SEI assessment questionnaire that is based on the CMM. The results of the
questionnaire are distilled to a single numerical grade that provides an indication
of an organization’s process maturity.
The SEI has associated key process areas (KPAs) with each of the
maturity levels. The KPAs describe those software engineering functions (e.g.,
software project planning, requirements management) that must be present to
satisfy good practice at a particular level. Each KPA is described by identifying
the following characteristics:
- Goals – the overall objectives that the KPA must achieve.
- Commitments – requirements (imposed on the organization) that must be
met to achieve the goals, or provide proof of intent to comply with the
goals.
- Abilities – those things must be in place (organizationally and technically)
to enable the organization to meet the commitments.
- Activities – the specific tasks required to achieve the KPA function.
- Methods for monitoring implementation – the manner in which the
activities are monitored as they are put into place.
- Methods for verifying implementation – the manner in which proper
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITYpractice for the KPA can be verified.
Q.4. Discuss the Water Fall Model for Software Development.
Answer.
The Linear Sequential Model:
Sometimes called the classic life cycle or the waterfall model, the linear
sequential model suggests a systematic, sequential approach to software
development that begins at the system level and progresses through analysis,
design, coding testing, and support. The linear sequential model for software
engineering. Modeled after a conventional engineering cycle, the linear sequential
model encompasses the following activities :
System / information engineering and modeling – because software is always
part of a larger system (or business), work begins by establishing requirements for
all system elements and then allocating some subset of these requirements to
software. This system view is essential when software must interact with other
elements such as hardware, people, and databases. System engineering and
analysis encompass requirements gathering at the system level, with a small
amount of top level design and analysis. Information engineering encompasses
requirements gathering at the strategic business level and at the business area
level.
Software requirements analysis - The requirements gathering process is
intensified and focused specifically on software. To understand the nature of the
program(s) to be built, the software engineer (“analyst”) must understand the
information domain for the software, as well as required function, behavior,
performance, and interface. Requirements for both the system and the software
are documented and reviewed with the customer.
Design – Software design is actually a multistep process that focuses on four
distinct attributes of a program : data structure, software architecture, interface
representations, and procedural (algorithmic) detail. Thedesign process translates
requirements into a representation of the software that can be assessed for quality
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITYbefore coding begins. Like requirements, the design is documented and becomes
part of the software configuration.
Code generation – The design must be translated into a machine-readable form.
The code generation step performs this task. If design is performed in a detailed
manner, code generation can be accomplished mechanistically.
Test – Once the code has been generated, program testing begins. The testing
process focuses on the logical internals of the software, ensuring that all
statements have been tested, and on the functional externals; that is, conducting
tests to uncover errors and ensure that defined input will produce actual results
that agree with the required results.
Support – Software will undoubtedly undergo change after it is delivered to the
customer (a possible exception is embedded software). Change will occur because
errors have been encountered, because the software must be adapted to
accommodate changes in its external environment (e.g. a change required because
of a new operating system or peripheral device), or because the customer requires
functional or performance enhancements. Software support / maintenance
reapplies each of the preceding phases to an existing program rather than a new
one. The linear sequential model is the oldest and the most widely used paradigm
for software engineering. However, criticism of the paradigm has caused even
active supporters to questions its efficacy [HAN95]. Among the problems that are
sometimes encountered when the linear sequential model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so
indirectly. As a result, changes can cause confusion as the project team
proceeds.
2. It is often difficult for the customer to state all requirements explicitly.
The linear sequential model requires this and has difficulty
accommodating the natural uncertainty that exists at the beginning of
many projects.
3. The customer must have patience. A working version of the program(s)
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITYwill not be available until late in the project time-span. A major blunder, if
undetected until the working program is reviewed, can be disastrous.
In an interesting analysis of actual projects Bradac [BRA94], found that
the linear nature of the classic life cycle leads to “blocking states” in which some
project team members must wait for other members of the team to complete
dependent tasks. In fact, the time spent waiting can exceed the time spent on
productive work ! The blocking state tends to be more prevalent at the beginning
and end of a linear sequential process. Each of these problems is real. However,
the classic life cycle paradigm has a definite and important place in software
engineering work. It provides a template into which methods for analysis, design,
coding, testing, and support can be placed. The classic life cycle remains a widely
used procedural model for software engineering. While it does have weaknesses,
it is significantly better than a haphazard approach to software development.
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
Traditional Software Configuration Management Process
Traditional SCM process is looked upon as the best fit solution to handling
changes in software projects. Traditional SCM process identifies the functional
and physical attributes of a software at various points in time and performs
systematic control of changes to the identified attributes for the purpose of
maintaining software integrity and traceability throughout the software
development life cycle.
The SCM process further defines the need to trace the changes and the
ability to verify that the final delivered software has all the planned enhancements
that are supposed to be part of the release.
The traditional SCM identifies four procedures that must be defined for
each software project to ensure a good SCM process is implemented. They are
Configuration Identification
Configuration Control
Configuration Status Accounting
Configuration Authentication
Most of this section will cover traditional SCM theory. Do not consider
this as boring subject since this section defines and explains the terms that will be
used throughout this document.
3.1. Configuration Identification
Software is usually made up of several programs. Each program, its
related documentation and data can be called as a "configurable item"(CI). The
number of CI in any software project and the grouping of artifacts that make up a
CI is a decision made of the project. The end product is made up of a bunch of
CIs.
The status of the CIs at a given point in time is called as a baseline. The
baseline serves as a reference point in the software development life cycle. Each
new baseline is the sum total of an older baseline plus a series of approved
changes made on the CI
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITY
A baseline is considered to have the following attributes
1. Functionally complete
A baseline will have a defined functionality. The features and
functions of this particular baseline will be documented and available for
reference. Thus the capabilities of the software at a particular baseline is well
known.
2. Known Quality
The quality of a baseline will be well defined. i.e. all known bugs will
be documented and the software will have undergone a complete round of
testing before being put define as the baseline.
3. Immutable and completely recreatable
A baseline, once defined, cannot be changed. The list of the CIs and
their versions are set in stone. Also, all the CIs will be under version control
so the baseline can be recreated at any point in time.
3.2. Configuration Control
The process of deciding, co-ordinating the approved changes for the
proposed CIs and implementing the changes on the appropriate baseline is called
Configuration control.
It should be kept in mind that configuration control only addresses the
process after changes are approved. The act of evaluating and approving changes
to software comes under the purview of an entirely different process called
change control.
3.3. Configuration Status Accounting
Configuration status accounting is the bookkeeping process of each
release. This procedure involves tracking what is in each version of software and
the changes that lead to this version.
Configuration status accounting keeps a record of all the changes made to
the previous baseline to reach the new baseline.
3.4. Configuration Authentication
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITYConfiguration authentication (CA) is the process of assuring that the new
baseline has all the planned and approved changes incorporated. The process
involves verifying that all the functional aspects of the software is complete and
also the completeness of the delivery in terms of the right programs,
documentation and data are being delivered.
The configuration authentication is an audit performed on the delivery
before it is opened to the entire world.
3.5. Tools that aid Software Configuration Management
Free Software Tools TODO: need some writeup here on each tool. Free
software tools that help in SCM are
Concurrent Versions System (CVS)
Revision Control System (RCS)
Source Code Control System (SCCS)
Commercial Tools
Rational ClearCase
PVCS
Microsoft Visual SourceSafe
3.6. SCM and SEI Capability Maturity Model
The Capability Maturity Model defined by the Software Engineering
Institute (SEI) for Software describes the principles and practices to achieve a
certain level of software process maturity. The model is intended to help software
organizations improve the maturity of their software processes in terms of an
evolutionary path from ad hoc, chaotic processes to mature, disciplined software
processes. The CMM is designed towards organizations in improving their
software processes for building better software faster and at a lower cost.
The Software Engineering Institute (SEI) defines five levels of maturity of
a software development process. They are denoted pictorially below.
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITY
Associated with each level from level two onwards are key areas which an
organization is required to focus on to move on to the next level. Such focus areas
are called as Key Process Areas (KPA) in CMM parlance. As part of level 2
maturity, one of the KPAs that has been identified is SCM.
Q.4. Explain
Answer:
I. Software doesn’t Wear Out.
Answer:
In 1970, less than 1% of the public could have intelligently described what
"computer software" meant. Today, most personal and many members of the
public at large feel that they understand software. But do they?
A text book description of software might take the following form:
Software is
(1) Instructions (computer programs) that when executed provide
desired function and performance,
(2) Data structures that enable the programs to adequately manipulate
information, and
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITY(3) documents that describe the operation and use of the programs.
There is no question that other, more complete definitions could be
offered. But we need more than a formal definition.
Software Characteristics to gain an understanding of software, it is important to
examine the characteristics of software that make it different from other things
that human beings build. When hardware is built, the human creative process
(analysis, design, construction, testing) is ultimately translated into a physical
form. If we build a new computer, our initial sketches, formal design drawings,
and bread boarded prototype evolve into a physical product (chips, circuit boards,
power supplies, etc).
Software is a logically rather than a physical system element. Therefore, software has characteristics that are considerably different than those of hardware:
1. Software is developed or engineered, it is not manufactured in the
classical sense.
Although some similarities exist between software development and hardware manufacture, the two activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software. Both activities are dependent on the people, but the relationship between people applied and work accomplished is entirely different. Both activities require the construction of a "product" but the approaches are different.Software costs are concentrated in engineering. This means that software projects can not be managed as if they were manufacturing projects.
2. Software doesn't "wear out."
Bath tub curve
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITY
Figure above depicts failure rate as a function of time for hardware. The
relationship often called the "bath tub curve" indicates that hardware exhibits
relatively high failure rates early in its life (these failures are often attributable to
design or manufacturing defects); defects are corrected and the failure rate drops
to a steady-state level (ideally, quite low) for some period of time. As time passes,
however, the failure rate rises again as hardware components suffer from the
cumulative effects of dust, vibration, abuse, temperature extremes, and any other
environmental maladies. Stated simply, the hardware begins to wear out.
Software is not suspect able to the environmental maladies that cause hardware to
wear out. In, theory, therefore, the failure rate curve for the software should take
the form of the "idealized curve". Undiscovered defects will cause high failure
early in the life of a program. However these are corrected (ideally, without
introducing other errors) and the curve flattens. However, the implication is
clear--software doesn't wear out. But it does deteriorate!
Idealized curve
3. Although the industry is moving towards component-based assembly,
most software continues to be custom built.
Consider the manner in which the control hardware for a computer-based
product is designed and built. The design engineer draws a simple schematic of
the digital circuitry, does some fundamental analyst to assure that proper function
will be achieved, and then goes to the shelf where catalogs of digital components
exist. Each integrated circuit (called an IC or a chip) has a part number, a defined
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITYand validated function, a well-defined interface, and a standard set of integration
guidelines. After each component is selected, it can be ordered off the shelf.
As an engineering discipline evolves, a collection of standard design
components is created. Standard screws andoff-the-shelfintegrated circuits are
only electrical engineers as they design new system. The reusable components
have created so that the engineer can concentrate on the truly innovative elements
of a design, that is, the parts of the design that represents something new. In the
hardware world, component reuse is a natural part of the engineering process. In
the software world, It is something that has only begun to be achieved on a broad
scale.
ii. Software is engineered & not manufactured.
Answer:
The roadmap to building high quality software products is software process.
Software processes are adapted to meet the needs of software engineers and
managers as they undertake the development of a software product.
A software process provides a framework for managing activities that can very
easily get out of control.
Different projects require different software processes.
The software engineer's work products (programs, documentation, data) are
produced as consequences of the activities defined by the software process.
The best indicators of how well a software process has worked are the quality,
timeliness, and long-term viability of the resulting software product.
Software Engineering
Software engineering encompasses a process, management techniques,
technical methods, and the use of tools.
Generic Software Engineering Phases
Definition phase - focuses on what (information engineering, software project
planning, and requirements analysis).
Development phase - focuses on how (software design, code generation, software
testing).
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITY Support phase - focuses on change (corrective maintenance, adaptive
Q.5. Explain the Different types of Software Measurement Techniques
Answer:
Software Measurement Techniques:
Measurements in the physical world can be categorized in two ways :
direct measures (e.g. the length of a bolt) and indirect measures (e.g. the “quality”
of bolts produced, measured by counting rejects). Software metrics can be
categorized similarly. Direct measures of the software engineering process
include cost and effort applied. Direct measures of the product include lines of
code (LOC) produced, execution speed, memory size, and defects reported over
some set period of time. Indirect measures of the product include functionality,
quality, complexity, efficiency, reliability, maintainability, and many other “-
abilities”.
1. Size Oriented Metrics:
Size-oriented software metrics are derived by normalizing quality and / or
productivity measures by considering the size of the software that has been
produced. If a software organization maintains simple records, a table of size-
oriented measures can be created. The table lists each software development
SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143
SIKKIM MANIPAL UNIVERSITYproject that has been completed over the past few years and corresponding
measures for that project. 12,100 lines of code were developed with 24 person-
months of effort at a cost $168,000. It should be noted that the effort and cost
recorded in the table represent all software engineering activities (analysis,
design, code, and test), not just coding. Further information for project alpha
indicates that 365 pages of documentation were developed, 134 errors were
recorded before the software was released, and 29 defects were encountered after
release to the customer within the first year of operation. Three people worked on
the development of software for project alpha.
2. Function Oriented Metrics:
Function-oriented software metrics use a measure of the functionality
delivered by the application as a normalization value. Since ‘functionality’ cannot
be measured directly, it must be derived indirectly using other direct measures.
Function-oriented metrics were first proposed by Albrecht [ALB79], who
suggested a measure called the function point. Function points are derived using
an empirical relationship based on countable (direct) measures of software’s
information domain and assessments of software complexity.
3. Extended Function Point Metrics:
The function point measure was originally designed to be applied to
business information systems applications. To accommodate these applications,
the data dimension (the information domain values discussed previously) was
emphasized to the exclusion of the functional and behavioral (control)
dimensions. For this reason, the function point measure was inadequate for many
engineering and embedded systems (which emphasize function and control). A
number of extensions to the basic function point measure have been proposed to
remedy this situation.
Q.6. Write a Note on Spiral Model.
Answer:
The spiral model is a software development process combining elements
of both design and prototyping-in-stages, in an effort to combine advantages of SANTOSH GOWDA.H Reg No.: 5210757283rd semester, Disha institute of management and technology Mobile No.: 9986840143