(0721330) Second Semester 2011/2012 Dr. Samer Odeh Hanna (PhD)

(0721330)Second Semester 2011/2012

Dr. Samer Odeh Hanna (PhD)http://philadelphia.edu.jo/academics/shanna

http://philadelphia.edu.jo/academics/shanna

Many models have been proposed to deal with the problems of defining activities and associating them with each other

The first model proposed was the waterfall model [Royce 1970]

Chapter 1: Life Cycle Modeling

RequirementsProcess

SystemAllocationProcess

ConceptExplorationProcess

DesignProcess

ImplementationProcess

InstallationProcess

Operation &Support Process

Verification& Validation

Process

The Waterfall Model of the Software Life Cycle

adapted from [Royce 1970]

Software Production 0721330 4

Problems with Waterfall Model

Managers love waterfall models: Nice milestones No need to look back (linear system), one activity at a

time Easy to check progress : 90% coded, 20% tested

Software development is iterative During design problems with requirements are

identified During coding, design and requirement problems are

found During testing, coding, design& requirement errors

are found => Spiral Model


Problems with Waterfall Model

Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway.

One phase has to be complete before moving onto the next phase.

Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.

Few business systems have stable requirements.


Evolutionary development [1]

The traditional waterfall life cycle has been the mainstay for software developers for many years. For software products that do not change very much once they are specified.

The waterfall model is still viable. However, for software products that have their feature sets redefined during development because of user feedback and other factors, the traditional waterfall model is no longer appropriate.


Evo

Exploratory development EVO uses small, incremental product releases,

frequent delivery to users Objective is to work with customers and to

evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.

Throw-away prototyping Objective is to understand the system

requirements. Should start with poorly understood requirements to clarify what is really needed.


(a) Traditional waterfall model. (b) Evolutionary (EVO) development model


EVO development model

Concurrentactivities

ValidationFinalversion

DevelopmentIntermediateversions

SpecificationInitialversion

Outlinedescription


Benefits of EVO

the biggest benefit of EVO is a significant reduction in risk for software projects. This risk might be associated with any of the many ways a software project can go awry, including missing scheduled deadlines, unusable products, wrong or poor quality. By breaking the project into smaller, more manageable pieces and by increasing the visibility of the management team in the project, these risks can be addressed and managed.

The inevitable change in expectations when users begin using the software system is addressed by EVO’s early and ongoing involvement of the user in the development process. This can result in a product that better fits user needs and market requirements.


Benefits of EVO (Cont.)

The opportunity to show their work to customers and hear customer responses tends to increase the motivation of software developers and consequently encourages a more customer-focused orientation.

The following figure illustrates the difference between the traditional life cycle and EVO in terms of how much user feedback can be expected during product development.


Amount of user feedback during (a) the traditional waterfall development process and (b) the evolutionarydevelopment process (EVO).


Component-based software engineering [3]

Component-based software development approach is based on the idea to develop software systems by selecting appropriate off-the-shelf components and then to assemble them with a well-defined software architecture.

Modern software systems become more and more large-scale, complex and uneasily controlled, resulting in high development cost, low productivity, unmanageable software quality and high risk to move to new technology Consequently, there is a growing demand of searching for a new, efficient, and cost-effective software development paradigm.


CBSD

One of the most promising solutions today is the component-based software development approach. This approach is based on the idea that software systems can be developed by selecting appropriate off-the-shelf components and then assembling them with a well-defined software architecture.

This new software development approach is very different from the traditional approach in which software systems can only be implemented from scratch. These commercial off-the shelf (COTS) components can be developed by different developers using different languages and different platforms. This can be shown in the following figure where COTS components can be checked out from a component repository, and assembled into a target software system.


CBSD


CBSD

Component-based software development (CBSD) can significantly reduce development cost and time-to-market, and improve maintainability, reliability and overall quality of software systems


Component’s Features

A component has three main features:

1) a component is an independent and replaceable part of a system that fulfills a clear function;

2) A component works in the context of a well defined architecture;

3) A component communicates with other components by its interfaces


The Life Cycle of Component-Based SoftwareSystems

Component-based software systems are developed by selecting various components and assembling them together rather than programming an overall system from scratch, thus the life cycle of component-based software systems is different from that of the traditional software systems. The life cycle of component-based software systems can be summarized as follows:

1) Requirements analysis; 2) Software architecture selection, construction, analysis, and

evaluation; 3) Component identification and customization;4) System integration; 5) System testing; 6) Software maintenance.


Cont.

The architecture of software defines a system in terms of computational components and interactions among the components. The focus is on composing and assembling components that are likely to have been developed separately, and even independently. Component identification, customization and integration is a crucial activity in the life cycle of component-based systems. It includes two main parts:

1) evaluation of each candidate COTS component based on the functional and quality requirements that will be used to assess that component; and

2) customization of those candidate COTS components that should be modified before being integrated into new component-based software systems.


References

1. Elaine L. May and Barbara A. Zimmer, “The Evolutionary Development Model for Software”, Hewlett-Packard Journal, (1996)

2. Walt Scacchi, “Process Models in Software Engineering”, Encyclopedia of Software Engineering, 2nd Edition, John Wiley and Sons, Inc, New York, (2001).

3. Xia Cai, Michael R. Lyu, Kam-Fai Wong, and Roy Ko, “Component-Based Software Engineering: Technologies, Development Frameworks, and Quality Assurance Schemes”, Lecture notes (2000).

Documents

(0721330) Second Semester 2011/2012 Dr. Samer Odeh Hanna (PhD)