III-I SOFTWARE ENGINEERING TOPICS UNIT-1.pptx

Software engineering

1. SOFTWARE ENGINEERING 1 By K N S K Santhosh Assistant professor

2. SOFTWARE ENGINEERING UNIT I: The Nature of Software, The Unique Nature of WebApps , Software Engineering, The Software Process, Software Engineering Practice, Software Myths. A Generic Process Model, Process Assessment and Improvement , Prescriptive Process Models, Specialized Process Models, The Unified Process, Personal and Team Process Models, Process Technology. UNIT II : Agility, Agility and the Cost of Change, Agile Process, Extreme Programming (XP), Other Agile Process Models , A Tool Set for the Agile Process, Software Engineering Knowledge, Core Principles, Principles That Guide Each Framework Activity, Requirements Engineering, Establishing the Groundwork, Eliciting Requirements , Developing Use Cases, Building the Requirements Model, Negotiating Requirements, Validating Requirements. UNIT III : Requirements Analysis, Scenario-Based Modeling , UML Models That Supplement the Use Case, Data Modeling Concepts, Class-Based Modeling , Requirements Modeling Strategies, FlowOrientedModeling , Creating a Behavioral Model, Patterns for Requirements Modelling, Requirements Modeling for WebApps .

3. UNIT IV : Design within the Context of Software Engineering, The Design Process, Design Concepts, The Design Model , Software Architecture, Architectural Genres, Architectural Styles, Assessing AlternativeArchitectural Designs, Architectural Mapping Using Data Flow, Components, Designing Class- BasedComponents , Conducting Component-Level Design, Component-Level Design for Web Apps, Designing Traditional Components, Component-Based Development.

4. Chapter 1 Software & Software Engineering 4

5. CONTENTS: The Nature of Software, The Unique Nature of WebApps , Software Engineering, The Software Process, Software Engineering Practice, Software Myths. A Generic Process Model, Process Assessment and Improvement, Prescriptive Process Models, Specialized Process Models, The Unified Process, Personal and Team Process Models, Process Technology. 5

6. What is Software? Software is: I nstructions (computer programs) that when executed provide desired features, function, and performance; ( 2) D ata structures that enable the programs to adequately manipulate information and ( 3) D ocumentation that describes the operation and use of the programs. 6

7. THE NATURE OF 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 do we continue to have difficulty in measuring progress as software is being developed and maintained? 7

8. What is Software ? Software is developed or engineered, it is not manufactured in the classical sense. Software doesn't "wear out." Although the industry is moving toward component-based construction, most software continues to be custom-built. 8

9. Wear vs. Deterioration 9

10. Software Engineering Some realities: A concerted effort should be made to understand the problem before a software solution is developed Design becomes a pivotal activity Software should exhibit high quality Software should be maintainable The seminal definition : Fritz Bauer defined as [Software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines . 10

11. 11 Software Engineering The IEEE definition: Software Engineering: ( 1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). 11

12. Software Applications System software Application software Engineering/scientific software Embedded software Product-line software Webapps (web applications) Artificial intelligence software 12

13. 13

14. Software—New Categories Open world computing— pervasive, distributed computing, wireless networks Netsourcing —the Web as a computing engine Open source —”free” source code open to the computing community (a blessing, but also a potential curse!) Also Data mining Grid computing Cognitive machines Software for nanotechnologies 14

15. Legacy Software Software must be adapted to meet the needs of new computing environments or technology. Software must be enhanced to implement new business requirements. Software must be extended to make it interoperable with other more modern systems or databases. Software must be re-architected to make it viable within a network environment . Why must it change? 15

16. 16 Unique Nature of Web Apps In the early days of the World Wide Web, websites consisted of little more than a set of linked hypertext files that presented information using text and limited graphics . As time passed, the augmentation of HTML by development tools (e.g., XML, Java) enabled Web engineers to provide computing capability along with informational content. Web-based systems and applications ( WebApps ) were born. Today, WebApps have evolved into sophisticated computing tools that not only provide stand-alone function to the end user, but also have been integrated with corporate databases and business applications.

17. Characteristics of WebApps - I Network intensiveness. A WebApp resides on a network and must serve the needs of a diverse community of clients. Concurrency. A large number of users may access the WebApp at one time. Unpredictable load. The number of users of the WebApp may vary by orders of magnitude from day to day. Performance. If a WebApp user must wait too long (for access, for server-side processing, for client-side formatting and display), he or she may decide to go elsewhere. Availability. Although expectation of 100 percent availability is unreasonable, users of popular WebApps often demand access on a “24/7/365” basis. 17

18. Characteristics of WebApps - II Data driven. The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end-user. Content sensitive. The quality and aesthetic nature of content remains an important determinant of the quality of a WebApp . Continuous evolution. Unlike conventional application software that evolves over a series of planned, chronologically-spaced releases, Web applications evolve continuously. Immediacy. Although immediacy —the compelling need to get software to market quickly—is a characteristic of many application domains, WebApps often exhibit a time to market that can be a matter of a few days or weeks. Security. Because WebApps are available via network access, it is difficult, if not impossible, to limit the population of end-users who may access the application. Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel. 18

19. A Layered Technology Software Engineering a “quality” focus process model methods tools 19

20. A Layered Technology QUALITY FOCUS Software engineering is a layered technology . A ny engineering approach must rest on an organizational commitment to quality. The bedrock that supports software engineering is a quality focus. 20

21. A Layered Technology PROCESS The software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework that must be established for effective delivery of software engineering technology. The software process forms the basis for mgmt control of software projects and establishes the context in which technical methods are applied, work products are produced, milestones are established, quality is ensured, and change is properly managed. 21

22. A Layered Technology METHODS Software engineering methods provide the technical how-to’s for building software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support . TOOLS Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering , is established. 22

23. Software Engineering Practice Polya suggests: 1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design). 3. Carry out the plan (code generation). 4. Examine the result for accuracy (testing and quality assurance ). 23

24. 24 1. Understand the Problem Who has a stake in the solution to the problem? That is, who are the stakeholders? What are the unknowns? What data, functions, and features are required to properly solve the problem? Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand? Can the problem be represented graphically? Can an analysis model be created? 24

25. 2. Plan the Solution Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required? Has a similar problem been solved? If so, are elements of the solution reusable? Can subproblems be defined? If so, are solutions readily apparent for the subproblems ? Can you represent a solution in a manner that leads to effective implementation? Can a design model be created? 25

26. 3.Carry Out the Plan Does the solution conform to the plan? Is source code traceable to the design model? Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm? 26

27. 4.Examine the Result Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented? Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements? 27

28. David Hooker’s General Principles 1: The Reason It All Exists 2: KISS (Keep It Simple, Stupid!) 3: Maintain the Vision 4: What You Produce, Others Will Consume 5: Be Open to the Future 6: Plan Ahead for Reuse 7 : Think! 28

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

30. Software Myths MANAGEMENT MYTHS We already have a books that full of standards and procedures for building software. Won’t that provide my people with everything they need to know? If we get behind schedule, we can add more programmers and catch up. If I decide to outsource the software project to a third party, I can just relax and let the firm built. 30

31. Software Myths CUSTOMER MYTHS A general statement of object is sufficient to begin writing programs we can fill the details later. Project requirement continually change, but change can be easily accommodated because software is flexible. 31

32. Software Myths Practitioner’s myths. Once we write the program and get it to work, our job is done. Until I get the program “running” I have no way of assessing its quality. The only deliverable work product for a successful project is the working program. Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down. 32

33. The Software Process A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which software engineering is to be applied. An action encompasses a set of tasks that produce a major work product (e.g., an architectural design model). A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome. 33 23

34. A Process Framework Process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities 34

35. Framework Activities A generic process framework for software engineering encompasses five activities: Communication Planning Modeling Analysis of requirements Design Construction Code generation Testing Deployment 35

36. 36 Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management 36

37. 37 A Generic Process Model

38. 38 Process Flow

39. 39 Identifying a Task Set A task set defines the actual work to be done to accomplish the objectives of a software engineering action. A list of the task to be accomplished A list of the work products to be produced A list of the quality assurance filters to be applied

40. 40 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. Stated in more general terms, a process pattern provides you with a template [amb98]— a consistent method for describing problem solutions within the context of the software process.

41. 41 Process Pattern Types Stage patterns —defines a problem associated with a framework activity for the process. Task patterns —defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice Phase patterns —define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature.

42. 42 Process Assessment and Improvement Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting and learning. CMM-Based Appraisal for Internal Process Improvement (CBA IPI) —provides a diagnostic technique for assessing the relative maturity of a software organization; SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessment. International Organization for Standardization ISO 9001:2000 for Software— a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides.

43. 43 Prescriptive Models 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?

44. Types of Prescriptive Models WATER FALL MODEL ITERATIVE MODEL V MODEL INCREMENT MODEL 44

45. 45 The Waterfall Model

46. 46

47. 47

48. 48

49. 49

50. 50

51. 51

52. 52

53. 53

54. 54

55. 55

56. 56

57. 57

58. 58

59. The V-Model As a software team moves down the left side of the V, basic problem requirements are refined into progressively more detailed and technical representations of the problem and its solution. Once code has been generated, the team moves up the right side of the V, essentially performing a series of tests(quality assurance actions) that validate each of the models created as the team moved down the left side.

60. 60

61. 61

62. 62

63. 63

64. 64

65. 65

66. 66

67. 67 The Incremental Model

68. 68

69. Incremental Model The incremental model combines elements of linear and parallel process flows. Incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces deliverable “increments” of the software The incremental process model focuses on the delivery of an operational product with each increment. 69 When to use Incremental Model Where requirements are clear and can implement by phase wise. requirements are divided into R1, R2………. Rn and delivered accordingly. Mostly such model is used in web applications and product based companies

70. Advantages Generates working software quickly and early during the software life cycle. More flexible – less costly to change scope and requirements. Easier to test and debug during a smaller iteration & Easier to manage risk. Each iteration is an easily managed milestone. Incremental Model allows partial utilization of the product and avoids a long development time. Generates working software quickly and early during the software life cycle. 70

71. Dis-advantages Each phase of an iteration is rigid and overlap each other. Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle. As additional functional is added to the product at every stage, problems may arise related to system architecture which was not evident in earlier stages. It needs good planning and design at every step. Needs a clear and complete definition of the whole system before it can be broken down and built incrementally. Total cost is higher than waterfall. 71

72. Evolutionary Process Models Software, like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds, making a straight line path to an end product unrealistic Prototyping model Spiral model 72

73. 1. Prototyping 73

74. 74

75. 75

76. 76

77. 77

78. 78

79. 79

80. 80

81. 81 2. Evolutionary Models: The Spiral

82. 82

83. The Spiral model The Spiral model is also called a Meta-Model because it subsumes all the other SDLC models. A single loop spiral represents the Iterative Waterfall Model. The spiral model incorporates the stepwise approach of the Classical Waterfall Model . The spiral model uses the approach of the Prototyping Model by building a prototype at the start of each phase as a risk-handling technique. Also , the spiral model can be considered as supporting the evolutionary model – the iterations along the spiral can be considered as evolutionary levels through which the complete system is built. 83

84. 84

85. 85

86. 86

87. 87

88. 88

89. 89

90. 90

91. Evolutionary Models: Concurrent The concurrent development model, sometimes called concurrent engineering, allows a software team to represent iterative and concurrent elements of any of the process models. E arly in a project the communication activity has completed its first iteration and exists in the awaiting changes state. The modeling activity which existed in the inactive state while initial communication was completed, now makes a transition into the under development state. If, however, the customer indicates that changes in requirements must be made, the modeling activity moves from the under development state into the awaiting changes state.

92. 92 Still Other Process Models Component based development —the process to apply when reuse is a development objective Formal methods —emphasizes the mathematical specification of requirements AOSD —provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process —a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

93. 93 The Unified Process (UP) inception elaboration

94. 94 UP Phases

95. 95 UP Work Products

96. Personal Software Process (PSP) The Personal Software Process (PSP) emphasizes personal measurement of both the work product that is produced and the resultant quality of the work product. In addition PSP makes the practitioner responsible for project planning (e.g., estimating and scheduling) and empowers the practitioner to control the quality of all software work products that are developed. The Personal Software Process (PSP) shows engineers how to manage the quality of their projects make commitments they can meet improve estimating and planning reduce defects in their products PSP emphasizes the need to record and analyze the types of errors you make, so you can develop strategies eliminate them 96

97. Personal Software Process (PSP) The PSP model defines five framework activities: Planning – isolates requirements and based on these develops both size & resource estimates. A defect estimate is made. High level Design – external specification of all components. All issues are recorded and tracked. High level Design Review- formal verification to uncover errors Development- metrics are maintained for all important tasks & work results. Postmortem- using measures & metrics collected effectiveness of process is determined an improved . 97

98. Team Software Process (TSP) The goal of TSP is to build a “self directed” project team that organizes itself to produce high-quality software. TSP defines the following framework activities: project launch, high-level design, implementation, integration and test, and postmortem. these activities enable the team to plan, design, and construct software in a disciplined manner while at the same time quantitatively measuring the process and the product. The postmortem sets the stage for process improvements. 98

99. 99

100. 100

101. PSP  TSP 1. PSP(Personal Software Process)provide a standard personal process structure for software developers 1. TSP (Team Software Process) is a guideline for software product Development teams. 2. PSP consists of a set of methods, tables, scripts etc. that serve as a guideline for software developers to plan, measure and manage their    Work, including how to define their processes and measure quality and productivity. 2. TSP focuses on helping development teams to improve their quality and productivity to better     meet goals of cost and progress.         3. PSP skills are used in a TSP team Environment. 3. TSP teams consist of PSP-trained developers who volunteer for areas of project responsibility, so the project is managed by the team Itself. 4. The PSP is a personal process that can be adapted to suit the needs of the individual developer. 4. TSP uses team based planning sessions  5. The Personal Software Process (PSP) is an SEI technology that brings discipline to the practices of individual software engineers for improving product quality and increasing cost.  5. The Team Software Process (TSP) is complementary SEI technology that enables teams     to develop software-intensive products more effectively. 101

102. 102 Team Software Process (TSP) Humphrey defines the following objectives for TSP: Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPT) of three to about 20 engineers. Show managers how to coach and motivate their teams and how to help them sustain peak performance. Accelerate software process improvement by making CMM Level 5 behavior normal and expected. Provide improvement guidance to high-maturity organizations. Facilitate university teaching of industrial-grade team skills.

103. What Is Team Software Process (TSP)? The Team Software Process (TSP), along with the Personal Software Process, helps the high-performance engineer to - ensure quality software products - create secure software products - improve process management in an organization 103

104. TSP Framework Activities Launch high level design Implementation Integration Test postmortem 104

105. TSP.. Engineering groups use the TSP to apply integrated team concepts to the development of software-intensive systems. A launch process walks teams and their managers through - establishing goals - defining team roles - assessing risks - producing a team plan 105

106. Benefits of TSP The TSP provides a defined process framework for managing, tracking and reporting the team's progress. Using TSP, an organization can build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams of 3 to 20 engineers. TSP will help your organization establish a nature and disciplined engineering practice that produces secure, reliable software.  106

107. PROCESS TECHNOLOGY One or more of the process models discussed in the preceding sections must be adapted for use by a software team. To accomplish this, process technology tools have been developed to help software organizations analyze their current process, organize work tasks, control and monitor progress, and manage technical quality. 107 PRODUCT AND PROCESS If the process is weak, the end product will undoubtedly suffer. But an obsessive over reliance on process is also dangerous.