2. WHAT IS SOFTWARE ENGINEERING?
Software engineering is an engineering that is concerned with
all aspects of software production.
Software, is any set of machine instructions to perform
specific operations.
Software Engineering is the application of a
systematic, disciplined, quantifiable approach to
Design
Development
Testing and
Maintenance and Evolution of a SOFTWARE.
3. Component-Based Software
Engineering
• Most of today’s applications are large and
complex.
• An application must have some additional
characteristics like usability, flexibility, simple
installation, reusability, portability,
interoperable, etc. to fight with the
advancement in the technology and rapidly
changing requirements
4. Component Based Development
(CBD)
• CBD can be best described by the following
two guiding principles:
– Reuse but do not reinvent;
– Assemble pre-built components rather than
coding line by line.
5. • Component Based Software Development
(CBSD) is getting popular in software industry
as a new effective development paradigm.
• It emphasizes the design and construction of
software system using reusable components.
• CBSD is capable of reducing development cost
and increasing the reliability of entire
software system using components.
6. Component
• A component is a Reusable and self -contained
piece of software with well-specified interface
that is independent of any application.
• It is an independent executable entity that can
be made up of one or more executable objects
• Size of a component may vary from simple
functions to an entire application systems
7. • New components can be developed, or even
acquired from third party.
• An extra effort must be paid for the additional
functionality of the component beyond the current
application’s need, to make the component more
useful
8. Reusability
• It is the degree to which a component can be
re-used and reduces the software
development cost by enabling less coding and
more integration
9. Implementation of Fuzzy System
for Estimation of Re-Usability
• Fuzzy based model for estimation of re-
usability considers five factors as inputs and
provides a crisp value of reusability
• All inputs can be classified into fuzzy sets
• The output reusability is classified as Very
High, High, Medium, Low and Very Low.
10. Estimating The Reusability
• To estimate reusability of Component Based
System, following factors have been identified:
– Customizability
– Interface Complexity
– Understandability
– Portability
11. • Customizability is defined as the ability to
modify a component as per the application
requirement
– Better reusability can be achieved if
customizability is high
– Customizability of a component may vary from 0
to 1.
12. • Interface Complexity:
– As components are black box in nature, we are
unable to get the source code of these
components.
– Interface acts as a main source for
understanding, use and implementation and
finally maintenance for the component.
– Therefore for better reusability, interface
complexity should be as low as possible .
13. • Understandability:
– Documentation provides the ease with which a user
can learn to operate, prepare inputs for, and interpret
outputs of a system or component.
– Better reusability can be achieved if
Understandability is better
• Portability
– It is the ability of a component to be transferred from
one environment to another. It is typically concerned
with reuse of component on new platforms.
14. • There are many rules fed to FIM such as:
– if Customizability of components is Low, Interaction
Complexity among component is High,
Understandability is Low, Commonality is Low and
Portability is Low then it is very difficult to maintain
the system i.e. Reusability will be Very Low.
– If Customizability of components is Low, Interaction
Complexity among component is High,
Understandability is Low, Commonality is Medium and
Portability is Medium then Reusability will be Low.
– Etc..,
15.
16. Requirements Engineering
• Many of the Software development phases
are highly communication-intensive activity
that involves analysts, architects, developers,
testers, business stakeholders, and end users.
• Among all the phases of software engineering,
requirements are key ingredient
• So, the focus of every development
methodology is on requirement engineering
phase.
17. • Software development involves roughly 50
percent computing and 50 percent
communication.
• Whenever human communication
involve, various linguistic variables come into
picture.
18. example
• For example, in object-oriented methods a candidate class
is generally identified by applying the rule:
• If an entity in a requirement specification is relevant and
exist autonomously then select it as a candidate class.
• This rule says "an entity is either a candidate class or not a
candidate class but not both".
• The software engineer may sometimes conclude that the
entity partially fulfils the relevance criterion, and may
prefer to define the relevance of an entity, for instance, as
substantially relevant. This definition would imply the
classification of the entity as a partial class, which is
considered as an inconsistent class definition by the current
object-oriented methods.
19. example
• The rule should have been:
• If an entity in a requirement specification is relevance-value
relevant and can exist autonomy value autonomous in the
application domain, then select it as a relevance-value relevant
candidate class. Here,
– relevance and autonomy are the properties (inputs)
– relevance-value and autonomy-value indicate the domains of these
properties.
– Based on these domains and rules for the relevance of candidate class,
we can get the crisp output of candidate class
• For example, relevance-value may represent the set of values
{Weakly, Slightly, Fairly, Substantially, Strongly}, and autonomy-
value may represent the set of values {Dependently, Partially
Dependently, Fully Autonomously}.
22. Size estimation
• To estimate the size of an object (to
be created) using the sizes of
predefined list of objects.
23. Advantages of size estimation
• Size estimation can be done in
advance to make better plans
• To assist in tracking progress
• to learn and build estimating skills.
24. Uncertainty in estimation
• Estimation is an uncertain process
• Earlier you try to estimate, the less is the
accuracy of estimation
25. Steps in size estimation
1. Gather size data on previously developed
programs.
2. Divide the historical product size data into
size ranges.
3. Compare the planned product with these
prior products.
4. Based on this comparison, select the size that
seems most appropriate for the new product.
26. Application of size estimation.
• A file utility of 1,844 LOC.
• A file management program of 5,834 LOC.
• A personnel record keeping program of 6,845
LOC.
• A report generating package of 18,386 LOC.
• An inventory management program of 25,943
LOC.
28. We will establish 5 size ranges, as follows:
3.122 – 3.409 (1,325 to 2,566) very small
3.409 – 3.696 ( 2,566 to 4,970) small
3.696 – 3.983 (4,970 to 9,626) medium
3.983 – 4.270 (9,626 to 18,641) large
4.270 – 4.557 (18,641 to 36,104) very large.
3.266 3.553 3.840 4.127 4.4143.122 3.409 3.696 3.983 4.270 4.557
29. • file utility very small
• file management program medium
• personnel record keeping programmedium
• A report generating package large
• An inventory management programvery
large
30. Analysis
• Suppose we want to estimate the size of a
program “Analyze marketing”
• It is a substantially more complex application
than either the file management or personnel
programs. It is not as complex as the inventory
management program and appears to have
significantly more function than the report
package. You conclude that the new program is in
the lower end of “very large,” or from 18 to 25
KLOC.
31. Drawbacks of size estimation
• It requires a lot of data.
• It only provides a crude sizing.
• It is not useful for programs much larger or
smaller than the historical data.