Sri Vidya College of Engineering & Technology-Virudhunagar

Transcription

1 Sri Vidya College of Engineering &Technology Department of Information Technology Class II Year (04 Semester) Subject Code CS6403 Subject SOFTWARE ENGINEERING Prepared By R.Vidhyalakshmi Lesson Plan for Introduction to Software Engineering Time: 50 Minutes Lesson. No Unit I Lesson No: 1/9 1.Content List: Introduction to Software Engineering 2.Skill addressed: Understand the Concepts of Software Engineering 3.Objectives of this Lesson Plan: To enable students to list the basic Concepts of Software Engineering 4.Outcome(s): Understanding And Analyse the basic concepts of Software Engineering 5.Link sheet: 1. What is Software? 2. What is Software Engineering? 3. What is Software Product? 4. What is Software Process? CS6403 SOFTWARE ENGINEERING Page 1

2 6.Evocation: (5 Minutes) Subject introduction (40 Minutes): Topics: 7.Lecture notes Introduction Examples: What is Software Engineering? INTRODUCTION TO SOFTWARE ENGINEERING AND PROCESS,PRODUCT Software engineering Software engineering is a discipline in which theories, methods and tools are applied to develop professional software. Software Software is nothing but a collection of computer programs that are related documents that are indented to provide desired features, functionalities and better performance. characteristics of the software a. Software is engineered, not manufactured. b. Software does not wear out. Most software is custom built rather than being assembled from components. various categories of software o System software o Application software o Engineering/Scientific software o Embedded software software process CS6403 SOFTWARE ENGINEERING Page 2

3 Software process is defined as the structured set of activities that are required to develop the software system fundamental activities of a software process Specification Design and implementation Validation Evolution 8.Textbook: T1: Roger S. Pressman, Software Engineering A practitioner s Approach, Sixth Edition, McGraw-Hill International Edition, Application: Business software, Data mining closely related to database CS6403 SOFTWARE ENGINEERING Page 3

4 Sri Vidya College of Engineering &Technology Department of Information Technology Class II Year (04 Semester) Subject Code CS6403 Subject SOFTWARE ENGINEERING Prepared By R.Vidhyalakshmi Lesson Plan for Life Cycle Model Waterfall, Prototyping,RAD model Time: 50 Minutes Lesson. No Unit I Lesson No: 2/9 1.Content List: Life Cycle Models 2.Skill addressed: Understand the Concepts of Software Engineering Life Cycle Model 3.Objectives of this Lesson Plan: To enable students to list the Life Cycle Model in Software Engineering 4.Outcome(s): Understandi And Analyse the basic concepts of Software Engineering Life cycle model 5. Link sheet: 1. Name the Evolutionary process Models 2. What are the merits of waterfall model? 3. What are the merits of waterfall model? 4. What are theadvantages &Disadvantages of waterfall model? CS6403 SOFTWARE ENGINEERING Page 4

5 6.Evocation: (5 Minutes) Subject introduction (40 Minutes): Topics: Introduction to lifecycle model Waterfall model, prototyping model RAD 7.Lecture Notes Waterfall model/linear Sequential Model/classic life cycle : Systems Engineering Software as part of larger system, determine requirements for all system elements, allocate requirements to software. Software Requirements Analysis Develop understanding of problem domain, user needs, function, performance, interfaces,. Software Design Multi-step process to determine architecture, interfaces, data structures, functional detail. Produces (high-level) form that can be checked for quality, conformance before coding. Coding Produce machine readable and executable form, match HW, OS and design needs. Testing Confirm that components, subsystems and complete products meet requirements, specifications and quality, find and fix defects. Maintenance Incrementally, evolve software to fix defects, add features, adapt to new condition. Often 80% of effort spent here! CS6403 SOFTWARE ENGINEERING Page 5

6 Waterfall model phases: Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase. Each phase terminates only when the documents are complete and approved by the SQA group. Maintenance begins when the client reports an error after having accepted the product. It could also begin due to a change in requirements after the client has accepted the product Waterfall model: Advantages: Disciplined approach Careful checking by the Software Quality Assurance Group at the end of each phase. Testing in each phase. Documentation available at the end of each phase. Waterfall model problems: It is difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. Few business systems have stable requirements. The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. The customer must have patience. A working version of the program will not be available until late in the project time-span Feedback from one phase to another might be too late and hence expensive. The Prototyping Models: Often, a customer defines a set of general objectives for software but does not identify detailed input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human machine interaction should take In this case prototyping paradigm may offer the best approach Requirements gathering Quick design Prototype building Prototype evaluation by customers Prototype may be refined Prototype thrown away and software developed using formal process{ it is used to define the requirement} Prototyping CS6403 SOFTWARE ENGINEERING Page 6

7 Strengths: Requirements can be set earlier and more reliably Customer sees results very quickly. Customer is educated in what is possible helping to refine requirements. Requirements can be communicated more clearly and completely Weaknesses: Requires a rapid prototyping tool and expertise in using it a cost for the development organisation Smoke and mirrors - looks like a working version, but it is not. The RAD Model: Rapid Application Development is a linear sequential software development process model that emphasizes an extremely short development cycle Rapid application achieved by using a component based construction approach If requirements are well understood and project scope is constrained the RAD process enables a development team to create a fully functional system Prototype thrown away and software developed using formal process{ it is used to define the requirement} Prototyping Strengths: Requirements can be set earlier and more reliably Customer sees results very quickly. Customer is educated in what is possible helping to refine requirements. Weaknesses: Requires a rapid prototyping tool and expertise in using it a cost for the development organisation Smoke and mirrors - looks like a working version, but it is not. The RAD Model: Rapid Application Development is a linear sequential software development process model that emphasizes an extremely short development cycle Rapid application achieved by using a component based construction approach If requirements are well understood and project scope is constrained the RAD process enables a development team to create a fully functional system Application generation Testing and turnover Business modeling: What information drives the business process? What information is generated? Who generates it? Data Modeling: The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics ( called attributes) of each object are identified and the relationships between these objects are defined CS6403 SOFTWARE ENGINEERING Page 7

8 Process modeling: The data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object Application generation: RAD assumes the use of 4 generation techniques. Rather than creating software using conventional 3 generation programming languages, the RAD process works to reuse existing program components (when possible) or created reusable components (when necessary) Testing and Turnover: Since the RAD process emphasizes reuse, many of the program components have already been testing. This reduces over all testing time. However, new components must be tested and all interfaces must be fully exercised Advantages &Disadvantages of RAD: Advantages Extremely short development time. Uses component-based construction and emphasises reuse and code generation Disadvantages Large human resource requirements (to create all of the teams). Requires strong commitment between developers and customers for rapid-fire activities. High performance requirements maybe can t be met (requires tuning the components). 8. Textbook: T1: Roger S. Pressman, Software Engineering A practitioner s Approach, Sixth Edition, McGraw-Hill International Edition, Application: Business software, Data mining closely related to database CS6403 SOFTWARE ENGINEERING Page 8

9 Sri Vidya College of Engineering &Technology Department of Information Technology Class II Year (04 Semester) Subject Code CS6403 Subject SOFTWARE ENGINEERING Prepared By R.Vidhyalakshmi Lesson Plan for Life Cycle Model Incremental model, Spiral model Time: 50 Minutes Lesson. No Unit I Lesson No: 3/9 1.Content List: Life Cycle Models 2. Skill addressed: o Understand the Concepts of Software Engineering Life Cycle Model 3.Objectives of this Lesson Plan: o To enable students to list the Life Cycle Model in Software Engineering 4.Outcome(s): o Understand And Analyze the basic concepts of Software Engineering Life cycle model 5. Link sheet: 1.What are the merits of incremental model? 2.What are the merits of spiral model 3.Define spiral model 6.Evocation: (5 Minutes) CS6403 SOFTWARE ENGINEERING Page 9

10 Subject introduction (40 Minutes): Topics: Introduction to incremental model Spiral model 7.Lecture Notes The Incremental Model The Incremental development Combination of linear + prototype Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality CS6403 SOFTWARE ENGINEERING Page 10

11 User requirements are prioritised and the highest priority requirements are included in early increments Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve Incremental development advantages: The customer is able to do some useful work after release Lower risk of overall project failure The highest priority system services tend to receive the most testing Spiral Model: Spiral model sectors: Customer communication Tasks required to establish effective communication between developer and customer Planning - The tasks required to define recourses, timelines, and project is reviewed and the next phase of the spiral is planned Risk analysis Risks are assessed and activities put in place to reduce the key Risks engineering Tasks required to build one or more representations of the application Construction & release Tasks required to construct, test, install and provide user support (e.g documentation and trainin Spiral Model Advantages: Focuses attention on reuse options. Focuses attention on early error elimination. Puts quality objectives up front. 8.Textbook: T1: Ian Sommerville, Software engineering, Seventh Edition, Pearson Education Asia, T2: Roger S. Pressman, Software Engineering A practitioner s Approach, Sixth Edition, McGraw-Hill International Edition, Application: Software field CS6403 SOFTWARE ENGINEERING Page 11

12 Sri Vidya College of Engineering &Technology Department of Information Technology Class II Year (04 Semester) Subject Code CS6403 Subject SOFTWARE ENGINEERING Prepared By R.Vidhyalakshmi Lesson Plan for SPM-Estimation and Loc based Estimation Time: 50 Minutes Lesson. No Unit I Lesson No: 4,5/9 1.Content List: Estimation and Loc based Estimation 2. Skill addressed: Understand the Concepts of SPM Estimation and Loc based Estimation 3.Objectives of this Lesson Plan: To enable students to list the SPM Estimation and Loc based Estimation 4.Outcome(s): Understandi And Analyse the basic concepts of SPM Estimation and Loc based Estimation 5.Link sheet: 1. Define SPM 2.What is meant by Loc based estimation? 6. Evocation: (5 Minutes CS6403 SOFTWARE ENGINEERING Page 12

13 Subject introduction (40 Minutes): 7.Lecture Notes Project Planning Software project planning encompasses five major activities Estimation, scheduling, risk analysis, quality management planning, and change management planning Estimation determines how much money, effort, resources, and time it will take to build a specific system or product The software team first estimates The work to be done The resources required The time that will elapse from start to finish Then they establish a project schedule that Defines tasks and milestones Identifies who is responsible for conducting each task Specifies the inter-task dependencies Estimation Planning requires technical managers and the software team to make an initial commitment Process and project metrics can provide a historical perspective and valuable input for generation of quantitative estimates Past experience can aid greatly Estimation carries inherent risk, and this risk leads to uncertainty The availability of historical information has a strong influence on estimation risk When software metrics are available from past projects Estimates can be made with greater assurance Schedules can be established to avoid past difficulties Overall risk is reduced Estimation risk is measured by the degree of uncertainty in the quantitative estimates for cost, schedule, and resources Nevertheless, a project manager should not become obsessive about estimation Plans should be iterative and allow adjustments as time passes and more is made certain Estimation of resources, cost, and schedule for a software engineering effort requires experience access to good historical information (metrics the courage to commit to quantitative predictions when qualitative information is all that exists Estimation carries inherent risk and this risk leads to uncertainty Project Estimation Project scope must be understood Elaboration (decomposition) is necessary Historical metrics are very helpful At least two different techniques should be used Uncertainty is inherent in the process Estimation Techniques Past (similar) project experience Conventional estimation techniques task breakdown and effort estimates size (e.g., FP) estimates Empirical models Automated tools CS6403 SOFTWARE ENGINEERING Page 13

14 Estimation Accuracy The degree to which the planner has properly estimated the size of the product to be built the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects) the degree to which the project plan reflects the abilities of the software team the stability of product requirements and the environment that supports the software engineering effort. Problem based Estimation In general, the LOC/pm and FP/pm metrics should be computed by project domain Important factors are team size, application area, and complexity LOC and FP estimation differ in the level of detail required for decomposition with each value For LOC, decomposition of functions is essential and should go into considerable detail (the more detail, the more accurate the estimate) For FP, decomposition occurs for the five information domain characteristics and the 14 adjustment factors External inputs, external outputs, external inquiries, internal logical files, external interface files Example of baseline productivity metrics are LOC/pm or FP/pm Making the use of single baseline productivity metric is discouraged In general, LOC/pm or FP/pm averages should be computed by project domain Local domain averages should be used Statistical approach three-point or expected-value estimate S = (s opt + 4s m + s pess )/6 S = expected-value for the estimation variable (size) s opt = optimistic value s m = most likely value s pess = pessimistic value CS6403 SOFTWARE ENGINEERING Page 14

15 Example Loc Based Estimation Function User interface and control facilities (UICF) Two-dimensional geometric analysis (2DGA) Three-dimensional geometric analysis (3DGA) Database management (DBM) Computer graphics display facilities (CGDF) Peripheral control function (PCF) Design analysis modules (DAM) Estimated LOC 2,300 5,300 6,800 3,350 4,950 2,100 8,400 Estimated lines of code 33,200 Estimated lines of code = W = 33,200 Let, Average productivity = 620 LOC/pm = X Labor rate = $8,000 per month = Y So, Cost per line of code = Z = Y/X = $13 (approx.) Total estimated project cost = W*Z = $431,000 (approx.) Estimated effort = W/X = 54 person-months (approx) 8.Textbook: T1: Roger S. Pressman, Software Engineering A practitioner s Approach, Sixth Edition, McGraw-Hill International Edition, 2005 CS6403 SOFTWARE ENGINEERING Page 15

16 Sri Vidya College of Engineering &Technology Department of Information Technology Class Subject Code II Year (04 Semester) CS6403 Subject SOFTWARE ENGINEERING Prepared By R.Vidhyalakshmi Lesson Plan for FP based Estimation Time: 50 Minutes Lesson. No Unit I Lesson No:6,/9 1.Content List: FP based Estimation 2.Skill addressed: Analyze and understanding the Concepts of FP based Estimation 3.Objectives of this Lesson Plan: To enable students to understand the FP based Estimation 4.Outcome(s): Understand And Analyse the FP based Estimation 5.Link sheet: 1. What is meant by Estimstion? 2. What is ment by FB based estimation? 6.Evocation: (5 Minutes) CS6403 SOFTWARE ENGINEERING Page

17 Subject introduction (40 Minutes): Topics: Example FB Based Estimation Information Domain Value Count Weighting factor Simple Average Complex External Inputs (EIS) 3 X = 9 External Outputs (EOs) 2 X = 8 External Inquiries (EQs) 2 X = 6 Internal Logical Files (ILFs) External Interface Files (EIFs) 1 X = 7 4 X = 20 Count Total 50 CS6403 SOFTWARE ENGINEERING Page

18 Fig.Value adjustment factor Now, FP estimated = count-total [ (F i )] F i (i = 1 to 14 are value adjustment factors) So, FP estimated = W = 320 [ ] = 375 (approx.) Let, Average Productivity = X = 6.5 FP/pm Labor rate = Y = $8,000 per month So, Cost per FP = Z = Y/X = $1,230 (approx.) Total estimated project cost = W*Z = $461,000 (approx.) Estimated effort = W/X = 58 person-months (approx) Empirical Estimation Models Uses empirically derived formulas to predict effort as a function of LOC or FP The empirical data are derived from a limited sample of projects So, no estimation model is appropriate for all classes of s/w and in all development environments The results obtained from such models must be used judiciously An estimation model should be calibrated to reflect local conditions Structure of Estimation model Derived using regression analysis on data collected from past s/w projects Overall structure, E = A + B (e v ) c Here, o A, B, and C are empirically derived constants o E is effort in person-months CS6403 SOFTWARE ENGINEERING Page

19 o e v is the estimation variable (either LOC or FP) Some form of project adjustment component is also used Example of a LOC-oriented estimation model (Bailey-Basili model) o E = (KLOC) 1.16 Example of a FP-oriented estimation model (Kemerer model) o E = FP Estimation models must be calibrated for local needs 8. Textbook: T1: Roger S. Pressman, Software Engineering A practitioner s Approach, Sixth Edition,McGraw-Hill International Edition, 2005 CS6403 SOFTWARE ENGINEERING Page

20 Sri Vidya College of Engineering &Technology Department of Information Technology Class II Year (04 Semester) Subject Code CS6403 Subject SOFTWARE ENGINEERING Prepared By R.Vidhyalakshmi Lesson Plan for COCOMO Model,Project scheduling Time: 50 Minutes Lesson. No Unit I Lesson No: 7,8/9 1.Content List: COCOMO Model,Project scheduling 2.Skill addressed: Analyze the Concepts of COCOMO Model,Project scheduling 3.Objectives of this Lesson Plan: 4.Outcome(s): 5. Link sheet: To enable students to understand the COCOMO Model,Project scheduling Understand And Analyze the COCOMO Model, Project scheduling 1. What is meant by COCOMO model? 2. Define Scheduling? 6.Evocation: (5 Minutes) Subject introduction (40 Minutes): Topics: COCOMO Model,Project scheduling 7.Lecture Notes COCOMO Model Stands for COnstructive COst MOdel Introduced by Barry Boehm in 1981 in his book Software Engineering Economics Became one of the well-known and widely-used estimation models in the industry It has evolved into a more comprehensive estimation model called COCOMO II COCOMO II is actually a hierarchy of three estimation models CS6403 SOFTWARE ENGINEERING Page

21 As with all estimation models, it requires sizing information and accepts it in three forms: object points, function points, and lines of source code Application composition model - Used during the early stages of software engineering when the following are important Prototyping of user interfaces Consideration of software and system interaction Assessment of performance Evaluation of technology maturity Early design stage model Used once requirements have been stabilized and basic software architecture has been established Post-architecture stage model Used during the construction of the software COCOMO Cost Drivers Personnel Factors Applications experience Programming language experience Virtual machine experience Personnel capability Personnel experience Personnel continuity Platform experience Language and tool experience Product Factors Required software reliability Database size Software product complexity Required reusability Documentation match to life cycle needs Product reliability and complexity Platform Factors Execution time constraint Main storage constraint Computer turn-around time Virtual machine volatility Platform volatility Platform difficulty Project Factors Use of software tools Use of modern programming practices Required development schedule Classified security application Multi-site development Requirements volatility Project Scheduling Split project into tasks and estimate time and resources required to complete each task Organize tasks concurrently to make optimal use of workforce Minimize task dependencies to avoid delays caused by one task waiting for another to complete Dependent on project managers intuition and experience Scheduling Problem Estimating the difficulty of problems and hence the cost of developing a solution is hard CS6403 SOFTWARE ENGINEERING Page

22 Productivity is not proportional to the number of people working on a task Adding people to a late project makes it later because of communication overheads The unexpected always happens. Always allow contingency in planning 8.Textbook: T1: Roger S. Pressman, Software Engineering A practitioner s Approach, Sixth Edition, McGraw-Hill International Edition, 2005 CS6403 SOFTWARE ENGINEERING Page

23 Sri Vidya College of Engineering &Technology Department of Information Technology Class II Year (04 Semester) Subject Code CS6403 Subject SOFTWARE ENGINEERING Prepared By R.Vidhyalakshmi Lesson Plan for Risk Management Time: 50 Minutes Lesson. No Unit I Lesson No: 9/9 1.Content List: Risk Management 2.Skill addressed: Analyze the Concepts of Risk Management 3.Objectives of this Lesson Plan: 4. Outcome(s): 5. Link sheet: To enable students to understand the Risk Management Understand And Analyse the Risk Management 1. What is meant by risk? 2. How to identify the risk? 6.Evocation: (5 Minutes) Subject introduction (40 Minutes): Topics: Risk Management CS6403 SOFTWARE ENGINEERING Page

24 7.Lecture Notes Risk Management Risks are potential problems that affect successful completion of project which involves Uncertainty and potential lose Risk analysis and management helps the s/w team to overcome the problems caused by the risks. The work product is called a Risk Mitigation, Monitoring and Management Plan(RMMMP). (a) risk strategies: * Reactive strategies: also known as fire fighting, project team sets resources aside to deal with the problem and does nothing until the risks became a problem. * Pro active strategies: risk management begins long before technical works starts, risks are Identified and prioritized by importance, the team lead builds a plan to avoid such risks. (b) S/W risks: * Project risk: * Technical risk: threaten product quality and time line * Business risk: threaten the validity of the s/w. * Known risk: predictable from careful evaluation of current project plan and those extrapolated from past project experience. * Unknown risk: some problems simply occur without warning. (c) Risk identification: * Product specific risk: the project plan and s/w statement of scope are examined to identify any specific characteristics. * Generic risk: Potential threads to any s/w products. (d) Risk impact: * Risk components: performance, cost, support, schedule * Risk impact: negligible, marginal, critical, catastrophic. The risk drivers affecting each risk component are classified according to their impact category and potential consequence of each undetected s/w fault. (e) Risk projection: Establish a scale that reflects the perceived likelihood of each risks. Delineate the consequence of the risk. Estimate the impact of the risk on project and product. (f) risk table construction: * List all risks in the first column of the table * Classify each risk and enter the category label in column 2 * Determine a probability for each risk and enter to third column. * Enter the severity of the risk in column 4. * Sort the table by probability and impact value. * First priority concerns must be managing(rmmm in fifth column). (g) assessing risk impact: * Factors affecting risk consequences: nature, scope, and timing of the risk. * If costs are associated with each risk table entry Halstead s risk exposure can be adopted and added to risk table. RE= probability * cost (h) risk assessment: * Defines referent levels for each project risk that can cause project termination. * Attempt to develop a relationship between each risk triple. * Predict the set of referent point that define a region of termination, bounded by a curve or areas of uncertainties. CS6403 SOFTWARE ENGINEERING Page

25 (i) risk refinement: * process of restating the risks as set of more detailed risk that will be easier to migrate, migrate, and manage. * CTC format may be a good representation for the detailed risk( condition transition consequence) (J) RISK MITIGATION, MONITORING AND MANAGEMENT: * Risk mitigation: proactive planning for risk avoidance * risk monitoring: accessing whether predicted risks occur or not, collect information for further risk analysis. * Risk management and contingency planning : actions to be taken in the event that mitigation step have failed and the risk become a life problem. (k) safety risks and hazards: Risks also associated with s/w failures that occur in the field after the development project has ended. Software safety and hazard analysis and quality assurance activity (l) risk information sheets: alternative to RMMM in which each risk is documented separately. RIS are maintain using a database system (m)examples: Pilot study Market research study of business impact risks Training (n) outline of risk management: identification-define risks for the project projection attempt to indicate quantitative likelihood that a risk will occur. Assessment evaluate the accuracy of projection and prioritize risks. Management and monitoring: move to avert those risks that are of concern and monitor all circumstance that may leave to risks. 1. risk identification: A systematic attempt to specify thread to the project plan. Both generic and product specific risks Risk identification : check list (i) people / staff (ii) customer / user (iii) business/business impact (iv) application, product size, technology (v) process maturity 2. risk projection: establish a scale that reflects the perceived likelihood of the risks. Define the consequence of the risks. Estimate the impact of the risk on the project and or the product 3. risk assessment: recording risks: building the risk table (i) estimate the probability of the occurrence (ii) estimate the impact on the project (iii) add RMMM plan CS6403 SOFTWARE ENGINEERING Page

26 (iv) sort the table by probability and impact 4. risk mitigation, monitoring and management: monitoring: what factors can be track that will enable us to determine the causes of risks. Management: what contingency plans do we have if the risks become a real 8. Textbook: T1: Roger S. Pressman, Software Engineering A practitioner s Approach, Sixth Edition, McGraw-Hill International Edition, 2005 CS6403 SOFTWARE ENGINEERING Page