Introduction to Software Engineering

1. UNIT-I Introduction to Software Engineering

2. Syllabus • Nature of Software • Software Process • Software Engineering Practice • Software Myths • Generic Process model • Process Assessment and Improvement • Perspective Process Models • Specialized Process Models • Personal and Team Process Models Agile Process models: • Agile process • Extreme programming

3. Nature of Software • Delivers Computing potential • It resides on various resources • Delivers imp product Time : Information • Gateway to worldwide information • Sophistication & complexity • Adoption of software engg practice

4. Defining Software • Software is: • instructions (computer programs) that when executed provide desired features, function, and performance • data structures that enable the programs to effectively manipulate information, and • descriptive information in both hard copy and virtual forms that describes the operation and use of the programs.

5. software characteristics • Software is developed or engineered; it is not manufactured in the classical sense. • Although the industry is moving toward component-based construction, most software continues to be custom built. • Software doesn’t “wear out.” But it does deteriorate!

6. Defining Software Software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to effectively manipulate information, and (3) descriptive information in both hard copy and virtual forms that describes the operation and use of the programs. • software characteristics • Software is developed or engineered; it is not manufactured in the classical sense. • Although the industry is moving toward component-based construction, most software continues to be custom built. • Software doesn’t “wear out.” But it does deteriorate!

7. Figure 1: Failure curve for hardware Figure 1.2: Failure curves for software

8. Software Application Domains • System software • Application software • Engineering/scientific software • Embedded software • Product-line software • Web applications • Artificial intelligence software

9. Legacy Software • Legacy software systems . . . were developed decades ago • Continually modified to meet changes • Must be adopted • Enhance to implement

10. Software Application Domains • System software • Application software • Engineering/scientific software • Embedded software • Product-line software • Web applications • Artificial intelligence software • Legacy Software Legacy software systems . . . were developed decades ago and have been continually modified to meet changes in business requirements and computing platforms

11. THE SOFTWARE PROCESS A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. A generic process framework for software engineering encompasses five activities: • Communication • Planning • Modeling • Construction • Deployment Software engineering process framework activities are complemented by a number of umbrella activities • Software project tracking and control • Risk management • Technical reviews • Measurement • Software configuration management • Reusability management • Work product preparation and production

12. SOFTWARE ENGINEERING PRACTICE • The Essence of Practice • Understand the problem (communication and analysis). • Plan a solution (modeling and software design). • Carry out the plan (code generation). • Examine the result for accuracy (testing and quality assurance). • General Principles • The Reason It All Exists • KISS (Keep It Simple, Stupid!) • Maintain the Vision • What You Produce, Others Will Consume • Be Open to the Future • Plan Ahead for Reuse • Think!

13. SOFTWARE MYTHS • Management myths Myth: We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know? Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called the “Mongolian horde” concept). Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm build it. • Customer myths Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in the details later.

14. Myth: Software requirements continually change, but change can be easily accommodated because software is flexible. • Practitioner’s myths Myth: Once we write the program and get it to work, our job is done. Myth: Until I get the program “running” I have no way of assessing its quality. Myth: The only deliverable work product for a successful project is the working program. Myth: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.

15. A GENERIC PROCESS MODEL A software process framework Process flow

16. A GENERIC PROCESS MODEL • Defining a Framework Activity • Identifying a Task Set • Process Patterns A process pattern describes a process-related problem that is encountered during software engineering work, identifies the environment in which the problem has been encountered, and suggests one or more proven solutions to the problem. Ambler has proposed a template for describing a process pattern: • Pattern Name • Forces • Type

17. PROCESS ASSESSMENT AND IMPROVEMENT • Standard CMMI Assessment Method for Process Improvement (SCAMPI) • CMM-Based Appraisal for Internal Process Improvement (CBA IPI) • SPICE (ISO/IEC15504) • ISO 9001:2000 for Software

18. PRESCRIPTIVE PROCESS MODELS 1. The Waterfall Model

19. PRESCRIPTIVE PROCESS MODELS 2. Incremental Process Models

20. PRESCRIPTIVE PROCESS MODELS • Evolutionary Process Models • Prototyping

21. PRESCRIPTIVE PROCESS MODELS II. The Spiral Model

22. PRESCRIPTIVE PROCESS MODELS 4. Concurrent Models

23. SPECIALIZED PROCESS MODELS • Component-Based Development • The Formal Methods Model • Aspect-Oriented Software Development

24. PERSONAL AND TEAM PROCESS MODELS • Personal Software Process (PSP) The PSP model defines five framework activities • Planning • High-level design • High-level design review • Development • Postmortem • Team Software Process (TSP)

25. AGILE PROCESS MODELS

26. AGILE PROCESS • What Is An Agile Process • Agility Principles • The Agile Alliance defines agility principles for those who want to achieve agility: • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

27. Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity—the art of maximizing the amount of work not done—is essential.

28. The best architectures, requirements, and designs emerge from self– organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. • The Politics of Agile Development • Human Factors • Competence. • Common focus • Collaboration. • Decision-making ability. • Fuzzy problem-solving ability • Mutual trust and respect • Self-organization

29. EXTREME PROGRAMMING (XP) • XP Values • The XP Process • Planning • Design • Coding • Testing • Industrial XP • Readiness assessment • Project community • Project chartering • Test-driven management • Retrospectives • Continuous learn • The XP Debate