You are on page 1of 69

Software Engineering

Subject Code: 3150711

Unit : 01
Introduction to
Software and
Software Engineering

Outline
 Software, Characteristics of Software, Software Application Domains
 Software Engineering, Software Engineering Layered Approach
 Software Process, Process Framework Activities , Umbrella Activities
 Software Myths
• Management Myth
• Customer Myth
• Practitioner's/Developer Myth)
 Software Process Models
• The Waterfall Model
• Incremental Process Model
• Prototyping Model, Spiral Model
• Spiral Model
• Rapid Application Development Model (RAD)
 Component based Development
WHY SOFTWARE ENGINEERING
Why to Study Software Engineering?

Before Software Engineering was not introduced.

1 2 3 4 5
How the How the How the How the How the
Customer Project System Programmer Business
Explains Leader Analyst Works Consultant
Requirement understand it design it on it describe it

4
Why to Study Software Engineering?

To avoid this we required software engineering.

6 7 8 9 10

How the What How the How it What the


Project Operations Customer was customer
documented Installed billed supported really get

5
Why to Study Software Engineering?

Customer Requirement Solution The software


• Have one trunk • Have one trunk engineering is required
• Have four legs • Have four legs to avoid the
• Should carry load both • Should carry load both communication gap
passenger & cargo passenger & cargo
• Black in color • Black in color
& to meet the actual
• Should be herbivorous • Should be herbivorous requirements of
customer
Our value within stipulated
budget
added,
& time
also gives
milk
6
Software Engineering
Engineering

Design Build Product


Software Engineering

7
Definition of Software Engineering

Software engineering has two parts: Software and Engineering.


Software is a collection of codes, documents, and triggers that
does a specific job and fills a specific requirement.
Engineering is the development of products using best
practices, principles, and methods.

Definition
software engineering is defined as a process of analyzing user
requirements and then designing, building, and testing
software application which will satisfy those requirements.
EVOLVING ROLE OF SOFTWARE
What is Software?

Software is

1)Computer program that when executed provide desired features, function & performance
2)Data Structure that enable programs to easily manipulate information
3)Descriptive information in both hard and soft copy that describes the operation and use of
programs
Thus we can define Software as a combination of computer program , Data Structure &
Descriptive information

Computer
+ Data
+ Documents
Program Structure Soft & Hard
10
Characteristics of Software
 Software is developed or engineered
 It is not manufactured like hardware
 Manufacturing phase can introduce quality problem that are nonexistent (or easily
corrected) for software
 Both requires construction of “product” but approaches are different
 Software doesn’t “wear-out” Change
Increate failure rate due to
side effect
Infant
“Wear out”
Failure Rate

Failure Rate
morality

Actual Curve

Idealized Curve
Time Time

Bathtub curve of hardware failure Software failure curve


11
Characteristics of Software
 Although the industry is moving towards component based construction,
most of the software continues to the custom built.
 In hardware world nowadays component reuses is a natural part of engineering whereas in
software world we have already achieved broad scale through custom software
Custom software development is the process of designing, creating, deploying and
maintaining software for a specific set of users or organizations. 

12
Software Application Domains

• System Software System


Software
• Application Software Point of Sale,
Artificial Customized
• Engineering / Application
intelligence Software
Software
Scientific Software Software
• Embedded Software Software
• Product line Application
Web Engineering
Software Domains / Scientific
Application
• Web Application Software

• Artificial intelligence
Software Product line Embedded
Software Software

13
Cont…
 System Software : System Software is necessary to manage the computer resources and
support the execution of application programs. Software like operating systems,
compilers, editors and drivers, etc., come under this category

 Application Software : Application software is designed to fulfill the user’s requirement


by interacting with the user directly. It could be classified into two major categories:-
generic or customized. Generic Software is the software that is open to all whereas
Customized software the software products which are designed as per the client’s
requirement

 Scientific Software : Scientific and engineering software satisfies the needs of a scientific
or engineering user to perform enterprise-specific tasks. Examples are software like
MATLAB, AUTOCAD, PSPICE, ORCAD, etc. 

14
Cont…

 Embedded Software : This type of software is embedded into the hardware


normally in the Read-Only Memory (ROM) as a part of a large system.
Examples are software used in instrumentation and control applications like
washing machines, satellites, microwaves, etc. 

 Product Line Software :It focuses on limited application but mass consumer
market for example word processing, spreedsheets , computer graphics,
multimedia, entertainment, databases etc.

15
Cont…

 Web application : The networking software is used when software is


running on a network of computers (such as the World Wide Web). It
includes all network management software, server software, security and
encryption software, and software to develop web-based applications like
HTML, PHP, XML, etc. 

 Artificial intelligence Software : Software like expert systems, decision


support systems, pattern recognition software, artificial neural networks,
etc. come under this category. They involve complex problems which are not
affected by complex computations using non-numerical algorithms.  

16
SOFTWARE CRISIS ON THE
HORIZON & SOFTWARE MYTHS
Software Myths
Most, experienced experts have seen myths or superstitions
(false beliefs) or misleading attitudes which creates major
problems for management and technical people.
These types of software-related myths are listed below.
Management Myths
Myth 1:
We have all the standards and procedures available for software development.
Fact:
Software experts do not know all the requirements for the software development.

Myth 2:
The addition of the latest hardware programs will improve the software
development.
Fact:
The role of the latest hardware is not very high on standard software
development; instead Engineering tools help the computer, they are more
important than hardware to produce quality and productivity.
Management Myths
Myth 3:
With the addition of more people and program planners to Software
development can help meet project deadlines (If lagging behind).
Fact: 
If software is late, adding more people will merely make the problem
worse. This is because the people already working on the project now
need to spend time educating the newcomers
Customers Myths
Myth 1:
A general statement of intent is enough to start writing plans (software development)
and details of objectives can be done over time.
Fact:
Official and detailed description of the database function, ethical performance,
communication, structural issues and the verification process are important.
Unambiguous requirements (usually derived iteratively) are developed only through
effective and continuous
communication between customer and developer.
Customers Myths
Myth 2:
Software requirements continually change, but change can be easily accommodated because
software is flexible
Fact:
It is true that software requirements change, but the impact of change varies with the time at
which it is introduced. When requirements changes are requested early (before design or code
has been started), the cost impact is relatively small. However, as time passes, the cost impact
grows rapidly—resources have been committed, a design framework has been established, and
change can cause upheaval that requires additional resources and major design modification.
Practitioner’s Myths
Myths 1:
They believe that their work has been completed with the writing of the plan.
Fact:
It is true that every 60-80% effort goes into the maintenance phase (as of the latter software release). Efforts are
required, where the product is available first delivered to customers.

Myths 2:
There is no other way to achieve system quality, until it is “running”.
Fact:
Systematic review of project technology is the quality of effective software verification method. These updates are
quality filters and more accessible than test.
Practitioner’s Myths
Myth 3:
An operating system is the only product that can be successfully exported project.
Fact:
A working system is not enough, the right document brochures and booklets are also required to provide guidance &
software support.

Myth 4: 
Engineering software will enable us to build powerful and unnecessary document & always delay us.
Fact: 
Software engineering is not about creating documents. It is about creating a quality product. Better quality leads to
reduced rework. And reduced rework results in faster delivery times
Software Engineering

Software engineering is the establishment and use of sound


engineering principles in order to obtain economically software that
is reliable and works efficiently in real machines.

Software Engineering is the science and art of building (designing and writing programs) a
software systems that are:
1) on time
2) on budget
3) with acceptable performance
4) with correct operation

25
Software Engineering Layered Approach

Software Engineering Tools allows automation of activities which


helps to perform systematic activities. A system for the support of
software development, called computer-aided software engineering
(CASE). Examples: Testing Tools, Bug/Issue Tracking Tools etc…

It provides technical how-to’s for building software, it


encompasses many tasks including communication,
requirement analysis, design modeling, program
construction, testing and support

It is a foundation of Software Engineering, It is the glue the


holds the technology layers, It defines a framework
activities
Defines continuous process improvement principles
26
Software Engineering Layered Approach Cont. Software Engineering is a layered technology

Quality
 Main principle of Software Engineering is Quality Focus.
 An engineering approach must have a focus on quality.
 Total Quality Management (TQM), Six Sigma, ISO 9001, ISO 9000-3, CAPABILITY MATURITY
MODEL (CMM), CMMI & similar approaches encourages a continuous process
improvement culture
Process Layer
 It is a foundation of Software Engineering, It is the glue the holds the technology layers
together and enables logical and timely development of computer software.
 It defines a framework with activities for effective delivery of software engineering technology
 It establish the context in which technical methods are applied, work products (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality is
ensured, and change is properly managed.

27
Software Engineering Layered Approach Cont.
Method
 It provides technical how-to’s for building software
 It encompasses many tasks including communication, requirement analysis, design
modeling, program construction, testing and support

Tools
 Software engineering tools provide automated or semiautomated support for the process
and the methods
 Computer‐aided software engineering (CASE) is the scientific application of a set of tools
and methods to a software system which is meant to result in high‐quality, defect‐free,
and maintainable software products.
 CASE tools automate many of the activities involved in various life cycle phases.

28
Software Process
 A process is a collection of activities, actions and tasks that are performed when some work product is to be created

 A process is not a rigid prescription for how to build the software, rather it is adaptable approach that enables the
people doing the work to pick and choose the appropriate set of work actions and tasks

 An activity try to achieve a broad objective (e.g., communication with stakeholders)

 An activity is applied regardless of the application domain, size of the project, complexity of the effort, or degree
of accuracy with which software engineering is to be applied.

 An action (e.g., architectural design) encompasses a set of tasks that produce a major work product (e.g., an
architectural design model).

 A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a noticeable
outcome.

 Each of these activities, actions & tasks reside within a framework or model
29
Software Process Software Process Framework
 Figure represents “The Software Process” Process framework
 Each framework activity is populated by Umbrella activities

set of software engineering actions framework activity #1


Software Engineering action #1.1
 Each software engineering action is
Task Sets

Software Process
Work tasks
defined by a task set that identifies work … Work products
to be completed, product to be … Quality assurance points

produced, quality assurance points & Software Engineering action #1.k


Task Sets Work tasks
milestones to indicate progress Work products

… Quality assurance points
The purpose of software process is
 to deliver software in timely manner and framework activity #n

 within sufficient quality to satisfy those


 Who has given proposal for software
development and
 Those who will use software
30
Process Framework Activities (CPMCD)
A process framework establishes the foundation for complete software engineering process, it encompasses five activities

Communication Communication with Planning Software Project Plan which defines


Customers / stockholders workflow that is to follow.
to understand project It describes technical task, risks,
requirements for defining resources, product to be produced
software features & work schedule

Modeling Creating models to Construction Code Generation


understand requirements (manual or automated)
and shows design of &
software to achieve Testing
requirements (to uncover errors in the code)

Deliver Software to Customer


Deployment Collect feedback from customer based on evaluation
Software Support
31
Umbrella Activities
 Umbrella activities applied throughout the software project &
help a software team to manage and control progress, quality,
change & risks
 Umbrella activities are those which keep
running in the background throughout
the software development

Software project Risk Software quality


It establish a
Tracking & Control Management assurance
skeleton
Technical Reviews Measurement
Reusability
architecture
Management for software
Software Configuration Management engineering
Work product preparation and production work.
32
Umbrella Activities Cont.
 Software project tracking and control: allows the software team to assess progress
against the project plan and take any necessary action to maintain the schedule.
 Risk management: assesses (evaluates) risks that may affect the outcome of the project
or the quality of the product.
 Software quality assurance: defines and conducts the activities required to ensure
software quality.
 Technical reviews: assesses software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
 Measurement: defines and collects process, project and product measures that assist the
team in delivering software that meets stakeholders’ needs.
 Software configuration management: it manages the effects of change throughout the
software process.

33
Umbrella Activities Cont.
 Reusability management: it defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
 Work product preparation and production: it encompasses (includes) the activities
required to create work products such as models, documents, logs, forms and lists.

34
Software Myths Beliefs about software and the process used to build it.

Management
Myths

Customer Myths

“Misleading Attitudes
that cause serious Practitioner's
(Developer)
problem” are myths. Myths

35
Management myth - 1 & 2

We have standards and procedures We have the newest computers


to build a system, which is enough. and development tools.

Reality Reality
 Are software practitioners aware of  It takes much more than the latest
standard’s existence? model computers to do high-quality
 Does it reflect modern software software development.
engineering practice?  Computer-aided software engineering
(CASE) tools are more important than
 Is it complete?
hardware.
 Is it streamlined to improve time to
delivery while still maintaining a focus on
quality?
 In many cases, the answer to all of these
questions is "no.“ 36
Management myth - 3 & 4

We can add more programmers and I outsourced the development


can catch up the schedule. activity, now I can relax and can wait
for the final working product.
Reality Reality
 Software development is not a  If an organization does not understand
mechanistic process like manufacturing. how to manage and control software
 In the words of Fred Brooks : "adding projects internally, it will invariably
struggle when it outsources software
people to a late software project makes it projects.
later."
 People who were working must spend
time educating the newcomers.
 People can be added but only in a planned
and well-coordinated manner.
37
Customer myth - 1 & 2
A general statement of objectives Requirement Changes can be easily
(requirements) is sufficient to start a accommodated because software is
development. very flexible.
Reality Reality
 Comprehensive (detailed) statements of  It is true that software requirements
requirements is not always possible, an change, but the impact of change
ambiguous (unclear) “statement of varies with the time at which it is
objectives” can lead to disaster. introduced.
 Unambiguous (clear) requirements can be  When requirements changes are
requested early the cost impact is
gathered only through effective and
relatively small.
continuous communication between
customer and developer.

38
Practitioner's (Developer) myth – 1 & 2

Once we write the program, our job I can’t access quality until it is
is done. running.

Reality Reality
 Experts say "the sooner you begin 'writing  One of the most effective software
code', the longer it will take you to get quality assurance mechanisms can be
done." applied from the beginning of a project
- the technical review.
 Industry data indicates that 60 to 80 %
effort expended on software will be after it  Software reviews are more effective
“quality filter” than testing for finding
is delivered to the customer for the first
software defects.
time.

39
Practitioner's (Developer) myth – 3 & 4

Working program is the only Software engineering is about


deliverable work product. unnecessary documentation.

Reality Reality
 A working program is only one part of a  Software engineering is not about
software configuration. creating documents. It is about creating
 A variety of work products (e.g., models, a quality product.
documents, plans) provide a foundation  Better quality leads to reduced rework.
for successful engineering and, more And reduced rework results in faster
delivery times.
important, guidance for software support.

40
Software Process Models The process model is the abstract representation of process.

 Also known as Software development life cycle SDLC


(SDLC) or Application development life cycle Phases
Communication
Models 1
 Process models prescribe a distinct set of
activities, actions, tasks and milestones
(deliverables) required to engineer high quality Deployment
5
SDLC Planning
2
software. Software
 Process models are not perfect, but provide Development
roadmap for software engineering work. Life
 Software models provide stability, control and Cycle
organization to a process that if not managed Construction Modeling
can easily get out of control. 4 3
 Software process models are adapted (adjusted)
to meet the needs of software engineers and
managers for a specific project.
41
Different Process Models
 Process model is selected based
on different parameters

 Type of the project & people

 Complexity of the project

 Size of team

 Expertise of people in team

 Working environment of team

 Software delivery deadline

42
Different Process Models
Process Models

Waterfall Model (Linear Sequential


Model)
Incremental Process Model
Prototyping Model
The Spiral Model
Rapid Application Development
Model
Agile Model

43
TYPES OF PROCESS MODEL

CONVENTIONAL PROCESS MODEL EVALUTIONARY PROCESS MODEL

 Waterfall Model (Linear Sequential  Incremental Model/Iterative Model


model)/classic life cycle  Spiral Model
 Prototype Model  Component Based Process Model
 RAD (Rapid Application Development )  Unified Process Model
Model

44
Classic life cycle or linear sequential model
The Waterfall Model

Communication
• Project initiation
• Requirements
Planning
gathering • Estimating
• Scheduling
Modeling
• Tracking • Analysis
• Design
Construction
• Coding
• Testing
Deployment
• Delivery
• Support
• Feedback

When requirements for a problems are well understood then this model is used
in which work flow from communication to deployment is linear
45
The Waterfall Model
When to use ? Advantages
 Requirements are very well known, clear  Simple to implement and manage
and fixed
 Product definition is stable Drawbacks
 Technology is understood  Unable to accommodate changes at later
 There are no ambiguous (unclear) stages, that is required in most of the
cases.
requirements
 Working version is not available during
 Ample (sufficient) resources with
development. Which can lead the
required expertise are available freely
development with major mistakes.
 The project is short
 Deadlock can occur due to delay in any
step.
 Not suitable for large projects.
 No parallism
46
Evolutionary Process Models
 When a set of core product or system requirements is well understood but the details of product or
system extensions have yet to be defined. (Customers have general objectives of software but do not
have detailed requirements for functions & features ).

 In this situation there is a need of process model which specially designed to accommodate product that
evolve with time.

 Evolutionary Process Models are specially meant for that which produce an increasingly more complete
version of the software with each iteration.

 Evolutionary Models are iterative.

 They are characterized in a manner that enables you to develop increasingly more complete versions of
the software.

 Evolutionary models are


 Prototyping Model
 Spiral Model
47
Prototyping model
When to use ?
 Customers have general objectives of software but do not have detailed requirements
for functions & features.
 Developers are not sure about efficiency of an algorithm & technical feasibilities.

 It serves as a mechanism for identifying software requirements.


 Prototype can be serve as “the first system”.
 Both stakeholders and software engineers like prototyping model
 Users get feel for the actual system
 Developers get to build something immediately

48
PROTOTYPE MODEL
 When the requirement are not clear then prototype model is used to finalize the
requirement.

 In prototype model customer involvement is present to finalize the requirement.

 In the early stage of the development SRS document contain the limited set of the
document.

 In this model developer will prepare quick design, build prototype ( WORKING MODEL) and
then take feedback from customer.

49
Prototyping model cont.
It works as follow
 Communicate with stockholders &
define objective of Software
Deployment & Communication
Feedback  Identify requirements & design quick plan

 Model a quick design (focuses on visible


part of software)
 Construct Prototype & deploy
Construction
of Prototype Quick Plan  Stakeholders evaluate this prototype and
provides feedback
 Iteration occurs and prototype is tuned
Modeling Quick based on feedback
Design
50
PROTOTYPE MODEL
 IF the customer feedback contain the additional set of the requirement the SRS document is
Modified repeatedly taking the same action until the customer is satisfied with the
prototype model.

 If the customer feedback does not contain any additional set of requirements then the
corresponding sample product ( PROTOTYPE MODEL) SRS document will be finalized.

 Only the prototype Model is called elicitation technique.

 After finalizing the sample model or prototype model two kinds of prototype model is used.

51
Prototyping model cont.
Problem Areas
 Customer demand that “a few fixes” be applied to make the prototype a working
product, due to that software quality suffers as a result
 Developer often makes implementation in order to get a prototype working quickly;
without considering other factors in mind like OS, Programming language, etc.
Advantages
 Users are actively involved in the development
 Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed
 Errors can be detected much earlier

52
RAD (RAPID APPLICATION DEVELOPMENT)
 RAD is used when the requirement is more clear and the schedule is very sort.

 In the RAD model to develop the operational final product in less time, there is a need of
modularity design.

 Modularity design is a decomposition(means break) technique that means divide the project
into sub modules, develop them simultaneously or parallelly.

 Latter integrate them to produce the final product.

 Before Approaching to the modularity design there is a need of considering the man power
requirement.

53
CONT...
 When the organization contain efficient man power then divide the man power into teams
and assign the independent modules into teams to develop simultaneously.

 Efficient Modularity design is associated with two factor.


 (i) Cohesion - high – one module will be independent from other module.
 (ii) Coupling means quantitative measure of what extent A module dependent of another
module.

54
Rapid Application Development Model (RAD) It is a type of
incremental model in
Team - 1 which; components or
Communication functions are
Modeling developed in parallel.
Construction
Planning • Integration
• Delivery Rapid development
Team - 2 • Feedback is achieved by
• Business
Modeling Modeling
component based
• Data Deployment construction
Modeling Construction
• Process
Modeling This can quickly
Team - 3 • Component
Reuse give the customer
Modeling • Automatic something to see
Code
Construction Generation
and use and to
• Testing provide feedback.
55
Rapid Application Development Model (RAD) Cont.
Communication  This phase is used to understand business problem.

Planning  Multiple software teams work in parallel on different systems/modules.

Modeling Construction
 Business Modeling: Information flow among the  It highlighting the use of pre-
business. existing software component.
 Ex. What kind of information drives (moves)?
 Who is going to generate information? Deployment
 From where information comes and goes?
 Integration of modules
 Data Modeling: Information refine into set of developed by parallel teams,
data objects that are needed to support delivery of integrated software
business. and feedback comes under
 Process Modeling: Data object transforms to deployment phase.
information flow necessary to implement
business. 56
Rapid Application Development Model (RAD) Cont.
When to Use?
 There is a need to create a system that can be modularized in 2-3 months of time.
 High availability of designers and budget for modeling along with the cost of automated
code generating tools.
 Resources with high business knowledge are available.
Advantages Drawback
 Reduced development time.  For large but scalable projects, RAD requires
sufficient human resources.
 Increases reusability of components.
 Projects fail if developers and customers are
 Quick initial reviews occur. not committed in a much shortened time-
 Encourages customer feedback. frame.
 Integration from very beginning  Problematic if system can not be modularized.
solves a lot of integration issues.  Not appropriate when technical risks are high
(heavy use of new technology). 57
EVOLUTIONARY PROCESS MODEL
 BY USING the evolutionary process model, we can develop the product functionality part by
part or release by release or category by category.

 After the same iteration the final product will be available in the customer place.

 Different framework are employed under this category

1. Incremental Model (Iterative enhancement Model)


2. Spiral Model
3. Component based process model
4. Unified process model

58
Incremental Process Model or Iterative Enhancement Model
 Incremental means MODULE BY MODULE.

 Maximum Customer Interactions.

 There are many situations in which initial software requirements are reasonably well
defined, but the overall scope of the development effort prevent a purely linear process.

 In addition, there may be a compelling need to provide a limited set of software


functionality to users quickly and then refine and expand on that functionality in later
software releases.

 In such cases, there is a need of a process model that is designed to produce the software in
increments.

59
Software Functionality & Features
Incremental Process Model

Project Calendar Time

 The incremental model combines elements of linear and parallel process flows.
 This model applies linear sequence in a iterative manner.
 Initially core working product is delivered.
 Each linear sequence produces deliverable “increments” of the software.

60
Incremental Process Model
e.g. word-processing software developed using the incremental model
 It might deliver basic file management, editing and
document production functions in the first
increment Advantages
 more sophisticated editing in the second increment;  Generates working software quickly
 spelling and grammar checking in the third and early during the software life
increment; and cycle.
 advanced page layout capability in the fourth  It is easier to test and debug during
increment. a smaller iteration.
When to use ?  Customer can respond to each built.
 When the requirements of the complete  Lowers initial delivery cost.
system are clearly defined and understood but  Easier to manage risk because risky
staffing is unavailable for a complete pieces are identified and handled
implementation by the business deadline. during iteration.
61
SPIRAL MODEL
 Spiral model is continuous improvement process model.

 This model is suitable to develop the complex systems because continuous qualitatively
feedback is accepted from the customer to improve the product functionality.

 In this model the product development is started from the core product to more
sophisticated(COMPLEX) product. LIKE BANKING SOFTWARE.

62
CONT...
IN THIS MODEL WE CONSIDER 6 ACTIVITIES

 Customer Communication
 Planning
 Risk Analysis
 Engineering
 Construction and release
 Customer Evaluation (Qualitatively feedback from the customer)

63
The Spiral Model

 It provides the potential for rapid


development.
 Software is developed in a series of
evolutionary releases.
 Early iteration release might be prototype but
later iterations provides more complete
version of software.
 It is divided into framework activities
(C,P,M,C,D). Each activity represent one
segment of the spiral
 Each pass through the planning region results
in adjustments to
 the project plan
 Cost & schedule based on feedback
64
The Spiral Model Cont.
When to use Spiral Model? Advantages
 For development of large  High amount of risk analysis hence, avoidance of Risk
scale / high-risk projects. is enhanced.
 When costs and risk evaluation  Strong approval and documentation control.
is important.  Additional functionality can be added at a later date.
 Users are unsure of their needs.  Software is produced early in the Software Life Cycle.
 Requirements are complex.
 New product line. Disadvantages
 Significant (considerable)  Can be a costly model to use.
changes are expected.  Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk
analysis phase.
 Doesn’t work well for smaller projects.
65
Component based Development
 Commercial off the shelf (COTS) software components are offered as product.
 COTS provides set of functionality with well defined interfaces that enables component to
be integrated into software.
 The component based development model incorporates many characteristics of the spiral
model.
 It is evolutionary in nature.
 Component based development model constructs applications from prepackaged software
components.
 Modeling and construction activities begin with the identification of components.

66
Component based Development
Component based development incorporates the following steps
1. Available component-based products are researched & evaluated for software
development.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Testing is conducted to insure proper functionality.

Advantages
 It leads to software reuse.
 It reduces development cycle time.
 Reduction in project cost.

67
Product & Process
 If the process is weak, the end product will suffer. But more confidence on process is also
dangerous.
 People gain more satisfaction from the creative process as they do from the end product.
 Like an artist enjoys the brush strokes as much as the framed result.
 A writer enjoys the search for the proper metaphor (comparison) as much as the finished book.
 As software professional, you should also derive as much satisfaction from the process as
the end product.
 The duality (contrast) of product and process is one important element in keeping creative
people engaged as software engineering continues to evolve.

68
Thank You…

You might also like