1. Software Engineering Introduction (The Process)

2. Objectives lTo define software engineering lTo introduce a range of software engineering process models lTo recap the properties and benefits of an Object Orientated approach

3. Software Engineering Defined lDef: The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines lDef: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software lSoftware engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available

4. Software Engineering a “quality” focus process model methods tools A Layered Technology  Focus: the underlying philosophy  Process: high level framework  Methods: technical tasks for building software  Tools: automated or semi-automated support (CASE)

5. Remember: High quality = project timeliness Why? Less rework! The Primary Goal: High Quality

6. Process: Generic Phases 1.Definition (“what”):  Establish what the requirements of the system are  Use system engineering, project planning, requirements analysis 2.Development (“how”):  Establish how the system is to be realized – design and build  Use software design, code generation, testing 3.Support:  Handle changes as the software environment evolves  Must handle four types of changes: correction, adaptation, enhancement, prevention 4.This process is complemented by a number of umbrella activities

7. Umbrella Activities lSoftware project management lFormal technical reviews lSoftware quality assurance lSoftware configuration management lDocument preparation and production lReusability management lMeasurement lRisk management

8. The Process Model: Adaptability lthe framework activities of a process model will always be applied on every project BUT lthe tasks (and degree of rigor) for each activity will vary based on:  the type of project (an “entry point” to the model)  characteristics of the project  common sense judgment  concurrence of the project team

9. The Fractal Model lAll stages of a software process coexist simultaneously at some level of detail lPractical processes attempt to bring order to this chaos status quo problem definition technical development solution integration status quo

10. The Linear (Waterfall) Model lAdapted from conventional engineering cycle lOldest and most widely used l(+) Works if requirements are well understood; (-) doesn’t handle iteration well, needs up front requirements, customers must be patience analysis designcodetest System/information engineering

11. The Prototyping Model lEarly versions of the software are for demonstration and refinement purposes. They are meant to be discarded. l(+) users get a feel for the system, developers learn how to build the real thing; (-) customer may imagine that the prototype is final, initial quick fix choices may be carried over to later development listen to customer build/revise mock-up customer test-drives mock-up

12. The RAD Model lRapid Application Development (RAD) uses component-based (4GL) techniques and requires well defined requirements l(+) rapid (60-90 days), (-) requires commitment from all parties, sufficient human resources, the right type of application business modeling data modeling process modeling application generation testing & turnover business modeling data modeling process modeling application generation testing & turnover business modeling data modeling process modeling application generation testing & turnover team #1 team #2 team #3 60 - 90 days

13. Evolutionary Models lMany systems evolve over time. lA process which develops increasingly more complete versions of the software is called for. lUnlike sequential because of iteration lUnlike prototyping because don’t throw away

14. The Incremental Model lDeliver increasing functionality at each increment. First iteration is the core. l(+) manages risk, deals well with staffing problems, (-) can be slow increment 2 increment 3 increment 4 increment 1 delivery of 1st increment delivery of 2nd increment delivery of 3rd increment delivery of 4th increment calendar time analysis designcodetest analysis designcodetest analysis designcodetest analysis designcodetest

15. The Spiral (Boehm) Model lEach turn has 3-6 task regions. Unlike incremental model software development requires the entire spiral l(+) considers entire software life cycle, good for large scale projects, (-) requires risk assessment expertise, not as widespread Customer Communication Planning Risk Analysis Engineering Construction and Release Customer Evaluation

16. The Component-Based (OO) Model lSimilar to spiral but uses pre-packaged classes wherever possible l(+) emphasises reuse, (-) must design with further reuse in mind

17. Other Process Models lConcurrent process model: recognizes that different stages of the project (analysis, design, coding) will have achieved different states (e.g. under development, awaiting changes, done, etc.) lFormal methods: the process to apply when a mathematical specification is to be developed lCleanroom software engineering: emphasizes error detection before testing. A variation of formal methods.

18. The Object Oriented Paradigm lObject technologies  reuse  faster software development and higher quality lObject oriented software is easier to maintain because the structure is inherently decoupled lEmploy the component-based process model to identify re-usable components lFor some systems, there may be an obvious mapping from real world entities to system objects

19. The OO Mindset problem domain objects

20. Classes lobject-oriented thinking begins with the definition of a class often defined as:  template  generalized description  pattern  “blueprint”... describing a collection of similar items la metaclass (also called a superclass) is a collection of classes lClasses bundle together attributes (data), methods (algorithms) and messages (communication) lonce a class of items is defined, a specific instance of the class can be created (an object)

21. Inside Objects sender object attributes: methods: receiver object attributes: methods: message: [receiver, operation, parameters] message: [sender, return value(s)]

22. Key OO Concepts lEncapsulation: Data and operations on the data are packaged together. This enables:  reuse of the object as a system component.  information hiding where the user is shielded from internal implementation details.  simpler communication lInheritance: A subclass inherits the attributes and methods of its superclass and can extend them. This enables:  Easy extension for reuse  But beware of multiple inheritance lPolymorphism (overloading): A number of different operations in different classes (often sharing a super-class) can have the same name. This enables:  Further decoupling of communication