Scribd
Upload
56 views4 pages

SWE211 Assignment

The document summarizes several software development process models and component-based software engineering models. It describes the waterfall model including the classical and iterative variations. Evolutionary development models covered include the spiral, incremental, and concurrent models. Component-based engineering models discussed are Enterprise JavaBeans, Component Object Model, X-MAN, and Common Object Request Broker Architecture.

Uploaded by

Rosemary
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
56 views4 pages

SWE211 Assignment

The document summarizes several software development process models and component-based software engineering models. It describes the waterfall model including the classical and iterative variations. Evolutionary development models covered include the spiral, incremental, and concurrent models. Component-based engineering models discussed are Enterprise JavaBeans, Component Object Model, X-MAN, and Common Object Request Broker Architecture.

Uploaded by

Rosemary
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

NAME: Sanni Rosemary Orahachi

MATRIC NO: 20L1SE88

COURSE CODE: SWE211

DEPT: Software Engineering

DATE: 18th June, 2022.

QUESTION
What are the sub process models we have?

ANSWER
1. Waterfall model
 Classical waterfall model
 Iterative waterfall model
2. Evolutionary development
 Spiral model
 Incremental model
 Concurrent development model
 WINWIN Spiral model
3. Component based software engineering
 Enterprise JavaBeans (EJB) model
 Component object model (COM)
 NET model
 X-MAN Component model
 Common object request broker architecture (COBRA)

Waterfall model
 Classical waterfall model
The classical Waterfall Model was the first Process Model. It is also known as a linear-
sequential life cycle model. It is very simple to understand and use.
Classical waterfall model is the earliest, best known and most commonly used methodology. It
is a sequential lifecycle that is simple to understand and use each phase has to be completed
finished before another start which means no overlapping is allowed.

 Iterative waterfall model

In practice, it is not possible to strictly follow the classical waterfall model for software
development work. In this context, we can view the iterative waterfall model as making
necessary changes to the classical waterfall model so that it becomes applicable to practical
software development projects. In Iterative waterfall model, the feedback paths are provided
from every phase to its preceding phase. The feedback paths allow for correction of the errors
committed during a phase, as and when these are detected in a later phase. For example, if
during a testing a design error is identified, then the feedback path allows the design to be
reworked and the changes to be reflected in the design documents. However, observe that
there is no feedback path to the feasibility stage. This means that the feasibility study errors
cannot be corrected.

Evolutionary development model

 Spiral model

The spiral model, initially proposed by Boehm, is an evolutionary software process model that
couples the iterative feature of prototyping with the controlled and systematic aspects of the
linear sequential model. It implements the potential for rapid development of new versions of
the software. Using the spiral model, the software is developed in a series of incremental
releases. During the early iterations, the additional release may be a paper model or prototype.
During later iterations, more and more complete versions of the engineered system are
produced.

 Incremental model

Incremental Model is a process of software development where requirements divided into


multiple standalone modules of the software development cycle. In this model, each module
goes through the requirements, design, implementation and testing phases. Every subsequent
release of the module adds function to the previous release. The process continues until the
complete system achieved.

 Concurrent model

Most of the successful software out there involves a series of phases of development, such as
requirements gathering and prototyping, that are put together to develop the software. These
phases are discrete and often performed concurrently. Often there is an intertwining between
the phases, which makes it inevitable to return to the earlier phases to make some changes
according to the results obtained in the later phases. This type of a model, in which multiple
phases are performed concurrently, can be coined as a concurrent model.

 WINWIN Spiral model


The spiral model suggests a framework activity that addresses customer communication. The
objective of this activity is to elicit project requirements from the customer. In an ideal context,
the developer simply asks the customer what is required and the customer provides sufficient
detail to proceed. Unfortunately, this rarely happens. In reality, the customer and the
developer enter into a process of negotiation, where the customer may be asked to balance
functionality, performance, and other product or system characteristics against cost and time
to market.
The best negotiations strive for a “win-win” result. That is, the customer wins by getting the
system or product that satisfies the majority of the customer’s needs and the developer wins by
working to realistic and achievable budgets and deadlines.
Boehm’s WINWIN spiral model defines a set of negotiation activities at the beginning of each
pass around the spiral. Rather than a single customer communication activity, the following
activities are defined:
1. Identification of the system or subsystem’s key “stakeholders.”
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win
conditions for all concerned (including the software project team).

Component based software engineering

 Enterprise JavaBeans model


Enterprise JavaBeans (EJB) is a Java Platform, Enterprise Edition (Java EE) Version 5
technology for the development and deployment of component-based business applications.
Although EJB is a powerful and useful technology, the programming model in version 2.X and
previous was complex and confusing, requiring the creation of multiple Java files and
deployment descriptors for even the simplest of EJB. This complexity hindered the wide
adoption of EJBs.

As a consequence, one of the central goals of Version 3.0 of the EJB specification is to make it
much easier to program an EJB, in particular by reducing the number of required
programming artifacts and introducing a set of EJB-specific metadata annotations that make
programming the bean file easier and more intuitive.

Another goal of the EJB 3.0 specification was to standardize the persistence framework and
reduce the complexity of the entity bean programming model and object-relational (O/R)
mapping model.

 Component object model


Component Object Model (COM) is a simple Microsoft specification method that defines a
binary standard for exchanging code between two systems, regardless of the OS or
programming language. COM provides access to distributed client object services and is used to
share cross-platform binary code and programming languages.

 X-MAN component model

X-MAN tool is the tool developed by the Component-based Software Development group at


University of Manchester.
X-MAN tool is developed using model-driven engineering. Essentially, X-MAN
is GME framework instantiated with meta-models of X-MAN component model. Additional
interpreters provide complete semantics of X-MAN component model and software
development methodology.
X-MAN tool development is supported by the European funded CESAR project.

 Common object request broker architecture(CORBA)

The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object


Management Group (OMG) designed to facilitate the communication of systems that are
deployed on diverse platforms. CORBA enables collaboration between systems on different
operating systems, programming languages, and computing hardware. CORBA uses an object-
oriented model although the systems that use the CORBA do not have to be object-oriented.
CORBA is an example of the distributed object paradigm

You might also like