Life Cycle Modeling

1. Life Cycle Modeling • 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]

2. Concept Exploration Process System Allocation Process Requirements Process Design Process Implementation Process Verification & Validation Process Installation Process Operation & Support Process The Waterfall Model of the Software Life Cycle adapted from [Royce 1970]

3. 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

4. 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.

5. 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.

6. 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.

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

8. EVO development model

9. 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.

10. 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.

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

12. 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.

13. 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.

14. CBSD

15. 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

16. Component’s Features • A component has three main features: • a component is an independent and replaceable part of a system that fulfills a clear function; • A component works in the context of a well defined architecture; • A component communicates with other components by its interfaces

17. 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: • Requirements analysis; • Software architecture selection, construction, analysis, and evaluation; • Component identification and customization; • System integration; • System testing; • Software maintenance.

18. 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: • evaluation of each candidate COTS component based on the functional and quality requirements that will be used to assess that component; and • customization of those candidate COTS components that should be modified before being integrated into new component-based software systems.

19. References • Elaine L. May and Barbara A. Zimmer, “The Evolutionary Development Model for Software”, Hewlett-Packard Journal, (1996) • Walt Scacchi, “Process Models in Software Engineering”, Encyclopedia of Software Engineering, 2nd Edition, John Wiley and Sons, Inc, New York, (2001). • 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).