Software Engineering Let’s learn the real engineering……….

1. Software EngineeringLet’s learn the real engineering………. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

2. LECTURE 1 Nature of Software , FAQ, Definition Hardware Vs Software, Bath tub curve , wear and deterioration Software application domain Software Myths This courseware material are to be used in conjunction with "Software Engineering: A practioner's Approach" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

3. Software Engineering? Lets first see what is a software …… and what do you know about it…… This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

4. FAQs about Software Why does it take so long to get software finished? Why are development costs so high? Why can’t we find all errors before we give the software to our customers? Why do we spend so much time and effort maintaining existing programs? Why is it difficult to measure the progress of software development? This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

5. Software??? … Definition Software is .. 1. Instructions that when executed provide desired features, function and performance 2. Data structures that enable the program to manipulate information. 3. Documentations or descriptive information in hard copy and virtual forms that describes the operation and use of programs. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

6. Software Vs. Hardware Software is developed or engineered, it is not manufactured in the classical sense. Software doesn’t wear out. Although the industry is moving towards component based construction, most software continues to be custom built. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

7. Characteristics of Software The software must be adapted to meet the needs of new computing environments. The software must be enhanced to implement new business requirements Must be extended to make it interoperable with other more modern systems or databases. Must be re-architected to make it viable within a network. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

8. Bath tub curve: Wear out of hardware This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

9. Software Failure Curve This courseware material are to be used in conjunction with "Software Engineering: A practioner's Approach" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

10. Software Application Domain System software Application software Engineering / Scientific software Embedded software Product-line software Web application Artificial intelligence software This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

11. Some Latest Application • Ubiquitous computing—wireless networks • Net sourcing—the Web as a computing engine • Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) • Also … (see Chapter 32) • Data mining • Grid computing • Cognitive machines • Software for nanotechnologies This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

12. Software Engineering Why is it required? 1. A concerned effort should be made to understand the problem before the software solution is developed. 2. Design of the software becomes a pivot activity. Software should exhibit high quality. Software should be maintainable. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

13. Software Engineering (Definition) It is the establishment of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machine. IEEE --- 1. The application of a systematic, disciplined, quantifiable approach to development, operation and maintenance of software, 2. Study the approaches as in 1. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

14. Software Myths Affect managers, customers (and other non-technical stakeholders) and practitioners Are believable because they often have elements of truth, but … Invariably lead to bad decisions, therefore … Insist on reality as you navigate your way through software engineering This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

15. Management Myths Myth1 : Having books & procedure developed for s/w development is enough. Reality : Are developers aware of their existence? Are these things are covering latest issues? Myth2 : Adding new programmers can catch the lagging schedule Reality : Training new people is always time consuming. Myth3 : Outsourcing is relaxing Reality : its not a solution. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

16. Customer myths Myth1 : A general objective statement of project is enough to start working Reality : Ambiguous statement will lead to wrong s/w Myth2 : S/W is flexible and so changes can be suggested later as well Reality : Impact of the change suggested in the later phase can lead to failure of s/w This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

17. Developer Myths Myth1 : Once we write the programs and get it to work, our job is done Reality : Sooner you begin the code writing, longer it will take you to finish Myth2 : Until I get the program running, I have no way of assessing its quality. Reality : SQA mechanism can be applied from the inception of the s/w. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

18. Developer Myths (Continued…) Myth3 : The only deliverable product of the software is working program Reality : Besides programs documents of software engineering and product support guideline should be provided. Myth4 : S/W engg. will make us to produce voluminous and unnecessary documents to produce and slow us down. Reality : Its not producing document but creating good quality s/w, which reduces rework, assures fast delivery This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

19. Core Software Engineering Principles The reason it all exists keep it simple! Maintain the product and project “vision” What you produce, others will consume Be open to the future Plan ahead for reuse Think! This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

20. Lecture 2 Layered Technology Generic Process, task ,Umbrella activities Water fall model, Incremental Model, RAD Model Introduction to Evolutionary Model This courseware material are to be used in conjunction with "Software Engineering: A practioner's Approach" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

21. A Layered Technology Software Engineering tools methods process model a “quality” focus Quality : TQM, Six Sigma Process Model : A framework i.e. responsible for mile stones, quality, work products Methods: Technical “how to”s Tools : Automated or simulated support for s/w development. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

22. A Process Framework • Process framework • Framework activities • work tasks • work products • milestones & deliverables • QA checkpoints • Umbrella Activities This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

23. Framework Activities • Communication • Planning • Modeling • Analysis of requirements • Design • Construction • Code generation • Testing • Deployment This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

24. Task Set Actual work to be done to accomplish the objectives of a software engineering action. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

25. Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

26. Process Patterns • Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors • A template is used to define a pattern • Typical examples: • Customer communication (a process activity) • Analysis (an action) • Requirements gathering (a process task) • Reviewing a work product (a process task) • Design model (a work product) This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

27. Process Model Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions … If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

28. Types of Process Model Linear Incremental Evolutionary This courseware material are to be used in conjunction with "Software Engineering: A practioner's Approach" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

29. The Waterfall Model This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

30. Waterfall Model : Disadvantages Real time projects rarely flow sequentially. It is often difficult for the customer to state all the requirements at a time. Customer need to be tolerant as the working model can not be viewed unless last phase ends. Any mistake left untouched will not get discovered and corrected till last phase. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

31. Incremental Model Staffing get managed. Delivery date is managed. Resources are managed. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

32. The Incremental Model This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

33. The RAD Model This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

34. RAD Features Rapid application. Communication: Understand business requirements. Planning : To work in parallel. Modeling: Data, Business, Process. Construction : Use of preexisting s/w components. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

35. Disadvantages Large team size. Developer and customer should be committed. Proper modeling required. High performance s/w can not be delivered- it requires to interface with system High technical risk… (non-availability of reusable component.) This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

36. Evolutionary Models: Prototyping Quick plan communication Modeling Quick design Deployment delivery & feedback Construction of prototype This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

37. Lecture 3 Evolutionary Models Spiral Model Prototype Model , Specialized process Models Concurrent Models This courseware material are to be used in conjunction with "Software Engineering: A practioner's Approach" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

38. Evolutionary Models: Prototyping Quick plan communication Modeling Quick design Deployment delivery & feedback Construction of prototype This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

39. Spiral Model Risk driven process model Anchor point milestones Concept development project ------- Prototype building -------New product Development project ------- Product enhancement project Applicable for large scale projects This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

40. Disadvantage High risk management is required Evolutions should be controlled and same should be convinced to customers. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

41. Evolutionary Models: The Spiral This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

42. Spiral Model Risk driven process model Anchor point milestones Concept development project ------- Prototype building -------New product Development project ------- Product enhancement project Applicable for large scale projects This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

43. Prototype Model Suitable when costumer is not in a position to state all the requirements. Suitable when new algorithms, operating systems are to be checked for adaptability. It has to be discarded once all the requirements are identified. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

44. Prototyping : Disadvantages Customer forgets that this is a prototype and can demand to convert the prototype into working project…. Or can claim for poor quality standards. Developer can choose inappropriate OS or language to develop prototype, and later continue with the same without caring about their pitfalls. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

45. Evolutionary Models: Concurrent This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

46. Lecture 4 Specialized process Model Formalized process Models RUP All four phases of RUP This courseware material are to be used in conjunction with "Software Engineering: A practioner's Approach" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

47. Specialized Process Models Component Based Development Formal Methods Model Aspect-Oriented Software Development This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

48. Component Based Development Available component-based products are researched and evaluated for the application in question. Component integration issues are concerned. A software architecture is designed to accommodate the components. Components are integrated into the architecture. Comprehensive testing is conducted to insure proper functionality. This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

49. Formal Methods Model • Activities leads to formal mathematical specification of the software. • Avoids • Ambiguity • Incompleteness • Inconsistency • Problems • Time consuming and expensive • Exhaustive training is required • Not suitable for non-technical customers This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and are provided with permission by R.S. Pressman and associates. Changes are made wrt Pune University Syllabus

50. Traditional Structured Analysis Described by W. W. Royce, 1970, IEEE WESCON, Managing the development of large software systems. Decomposition in terms of Function and Data Modularity available only at the file level cf. C language's static keyword (=="file scope") Data was not encapsulated: Global Scope File Scope Function Scope (automatic, local) Waterfall Method of Analysis and Design