Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 1: Introduction Omar Meqdadi SE 3860 Lecture 1 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.

Similar presentations


Presentation on theme: "Chapter 1: Introduction Omar Meqdadi SE 3860 Lecture 1 Department of Computer Science and Software Engineering University of Wisconsin-Platteville."— Presentation transcript:

1 Chapter 1: Introduction Omar Meqdadi SE 3860 Lecture 1 Department of Computer Science and Software Engineering University of Wisconsin-Platteville

2 2 Topic Covered Introduction

3 3 Development/Maintenance/ Evolution Development is implementation of a new software system. Maintenance consists of activities required to keep software operational after it is placed into production. Evolution is a process which changes an existing software so that it satisfies a new set of requirements.

4 4 Phases of Software Life Cycle Definition Phase - behavior of the system Development Phase - How to obtain the desired behavior Maintenance - change the behavior

5 5 Software Process Models Classical Process Models  Waterfall  Linear Sequential  Prototyping Model  Rapid Application Development Evolutionary Process Models  Incremental Model  Spiral Model  Component Assembly Model  Concurrent Development Model

6 6 Classical Lifecycle Model Requirements Phase Specification Phase (Analysis) Planning Phase Design Phase Implementation Phase Integration and Testing Maintenance Retirement

7 Sequential Model Requirements Testing/Verify Integration Testing/Verify Operations Mode Specification Testing/Verify Planning Testing/Verify Design Testing/Verify Implementation Testing/Verify Maintenance

8 8 Evolutionary Process Models All software evolves (changes) over time Requirements change over the lifetime of the project Time to market means we cannot wait until the very end of the project for a solution Must make efficient use of team members Iterative model Develop increasingly more complex versions of the software

9 9 Incremental Model linear sequential model with prototyping Produces increments of a system. First produce the core product A set of new functionality is added in each new increment (maintenance) The first increment can be viewed as a prototype that is used by the client Overlapping sequences of process stages Focus on a set of deliverables Allows workers dedicated to a particular stage, e.g., “short, wide” developers

10 10 Spiral Model Software is developed in a set of incremental releases Early iterations may be prototypes or paper models Later iterations are increasingly more complex versions of the software (maintenance) Divided into a number of framework activities or task regions (typically between 3 and 6) Allows for efficient use of resources

11 11 Spiral Model

12 12 Component-Based Software Engineering Based on systematic reuse  Systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems Process stages  Component analysis  Requirements modification (maintenance)  System design with reuse  Development and integration This approach is becoming increasingly used as component standards have emerged

13 13 Reuse-Oriented Development

14 14 Problems with Software Production The hard part of building software is the specification and design, not the coding! Why?  Complexity  Conformity  Changeability  Invisibility

15 15 Complexity Software is complex and it will only get more complex Why?  Communication among team members  Enumeration/Understanding of program states  Function invocations  Trying to extend the functionality

16 16 Conformity No underlying basic theory Must conform to the current environments, interfaces, hardware, etc. Conformity increases complexity

17 17 Changeability Software is always subject to change The more successful a software system is the more likely hood it will be changed Requirements and specification are a moving target.

18 18 Invisibility No “floor plan” for a large piece of software Multiple very large complex multiple- dimensional views are needed for a software system “floor plan”. Restricting program structure is not an option – (see complexity)

19 19 Complaints Software is unreliable and needs permanent maintenance Software is messy, lacks transparency, prevents improvement or building on (or costs too much to do so)

20 20 Fact1 50% of all software projects fail  Never delivered/completed  Do not meet requirements or user needs  Excessive failures (bugs)  Excessively over budget or late

21 21 Fact2: Cost to Fix Faults


Download ppt "Chapter 1: Introduction Omar Meqdadi SE 3860 Lecture 1 Department of Computer Science and Software Engineering University of Wisconsin-Platteville."

Similar presentations


Ads by Google