343 CS Software Engineering

1. 343 CS Software Engineering MujthabaGulamMuqeeth Lecturer, Salman Bin Abdulaziz University, College of Arts and Science Wadidawassir.

2. Week 1 • Topics to be covered.. • Software • Software Engineering • Attributes of good software

3. Fundamentals of Software Engineering • Software: It is defined as set of programs consisting of code to perform any task. • . Software products may be developed for a particular customer or may be developed for a general market. • What is software engineering? • Software engineering is an engineering discipline that is concerned with all aspects of software production.

4. Cond.. • Software engineering is the branch of systems engineering concerned with the development of large and complex software intensive systems. • Software Engineering Applications: • The real-world goals for, services provided by, and constraints on such systems. • the precise specification of system structure and behavior, and the implementation of these specifications. • The activities required in order to develop an assurance that the specifications and real-world • goals have been met; • The evolution of such systems over time and across system families.

5. What are the attributes of good software? Good software should deliver the required • Functionality • Performance • Maintainable • dependable • usable. • Efficiency

6. Week 2Introduction Software Development life-cycle and learning various problem solving techniqes • Phases of SDLC • Example projects. • Problem solving techiniques.

7. S.D.L.C. Requirements: • This is the first initiation step. • In this phase all the requirement of the customer will be collected and prepared in the form of document. • This is the phase where the customer and software person will be interacted. • All the phases of SDLC will be depend on this phase.

9. Analysis: • Once the requirement are collected is given to analysis. • He elaborates the problem and find various ways top solve it. • He will do the analysis of all the ways for solving the problem and select the best one.

10. Modeling: • In this the various blue prints of the software is created. • Different models are created for different levels of abstractions. • It proposes 9 diagrams usecase, Sequence, collabration, activity, statechart, object, class, component and deployment diagrams.

11. Design: This is the phase where the requirements of the customers are mapped to the implementation level. • Class diagrams are generated n this phase.

12. Testing • This is the phase where all the requirements of the customer are checked whether it meets or not. • This phase where test cases are generated for testing the software

13. Maintenance: • this is the step where the software is delivered to the customer. • Regular feed backs are collected form the customer. • If any changes had to be made again all the phase are created.

14. Problem Solving Techniques • 1.Complete study of problem. • 2.Expand the problem • 3.Find the various ways to solve it (Analysis). • 4.Pick the best method to solve(Design). • 5.Implement it.

15. 1.First we decide the problem type whether simple or complex. • 2.We find the various ways to solve it by analysis.Eg.Algorithms,Flowcharts,DFD’s and so on. • 3.We pick the best solution to solve the problem(Design). • 4.We implement it by using any software.

16. Example Projects • Bank ATM • Library • Transport systems. • University.

17. Week 3Various process models and there assessments. • Water fall model • RAD model • Incremental • spiral model • CMMI model and its stages • All model advantages and disadvantages.

18. Water fall model. • This is the first model to create SDLC. • It contains same 7 phases of SDLC like requirements, Analysis, Modeling, Design,Coding,Testing and Maintenance. • Explain again the phases. The main drawback • The customer interaction will not be there after first phase. • Any change will go through to repeat all the phases.

19. Waterfall Model – Revisited • Disadvantages of Waterfall Model • 1. Real projects are rarely so straightforward and sequential • 2. It is generally not possible to completely define (and freeze) all the requirements at the start of the project • 3. Problem is discovered in testing? • 4. Freight-Train Effect, or Late, or Over-Budget

20. Incremental Model • This is developed to overcome the drawback of waterfall model. • This contains all the phases of SDLC. • This models are broken into modules. • Each model produce the temporary product iterations. • All the iteration lead to final product development. • The customer interactions will be there even after the requirement phase

21. Advantages of Incremental model • Correct the drawback of waterfall model. • Cheap when compared to waterfall model. • Planning to made for the regular breakdown in modules. • The customer interaction is present after the requirement phase also. • Disadvantages: Proper planning concentration should be made in break down. • Improper planning more number of iterations.

22. Iterative models

23. Rapid Application Development Model (R.A.D) • This contains quick requirements, analysis, modeling, design, coding, testing, maintenance done. • A Prototype is given after every phase and changes will be made if required.

24. Case Study- RAD Grand Community Calendar Project • Project Manager, Developer, Community Members write user requirements • Coder writes sample HTML • Shows the web page; heads bob, some changes to navigation • DBA, Coder, Project Manager determine the architecture (Design) • Coding & Review • Shifting Requirements priced project out-of-budget

25. Spiral Model Determine objectives, alternatives, constraints Evaluate alternatives, identify and resolve risks Plan next phases Develop verify next level product

26. Risk Assessment • Spiral Model – risk driven rather than document driven • The "risk" inherent in an activity is a measure of the uncertainty of the outcome of that activity • High-risk activities cause schedule and cost overruns • Risk is related to the amount and quality of available information. The less information, the higher the risk • What happened with Denver Airport Luggage System?

27. Strengths Introduces risk management Prototyping controls costs Evolutionary development Release builds for beta testing Marketing advantage Weaknesses Lack of risk management experience Lack of milestones Management is dubious of spiral process Change in Management Prototype Vs Production Spiral ModelStrength and Weaknesses

28. CMMI (Capability Maturity Model Integration ) • It is process improvement approach] • Essential elements of effective process. • Improve performance • Divide the work groups, projects, divisions the entire organization. • Improve effectiveness, quality and efficiency. • Practices cover topics that include causal analysis; configuration management; quality assurance; verification and validation; risk management; requirements management; supplier management; project management; interface compatibility; make, buy, or reuse analysis; capacity management; availability management; disaster recovery, data collection .

29. CMMI (Capability Maturity Model Integration ) • It is process improvement approach] • Essential elements of effective process. • Improve performance • Divide the work groups, projects, divisions the entire organization. • Improve effectiveness, quality and efficiency. • Practices cover topics that include causal analysis; configuration management; quality assurance; verification and validation; risk management; requirements management; supplier management; project management; interface compatibility; make, buy, or reuse analysis; capacity management; availability management; disaster recovery, data collection .

30. CMMI (Capability Maturity Model Integration ) • Level 5: Optimizing • Management : - • Organizational : Technology change management Process change management.Engineering : Defect Prevention. • Level 4 : Level Managed • Management : Quantitative processes management. • Organizational : - • Engineering : Software Quality Management.

31. Level 3 • Management: Integrated Software Management Intergroup Coordination.Organizational: Focus process Organization ,Organization Process Definition ,training program. • Engineering: Software product engineering, peer reviews. • Level 2 : Requirement management ,software project planning, • Software project tracking oversight, software subcontract management, software Quality assurance software configuration management. • Organizational: • Engineering

32. Level 1: • Management : Ad Hoc Process • Organizational : • Engineering:

33. Week 4 Software metrics and requirement elicitation • Software metrics & their performance. • Reqquirement engineering tasks • Eliciting requirements • Functional & • Non fucntional requirements.

34. Metrics • Software metric is a measure of some property of a piece of software or its specifications • It is used to measure the quantitative and qualitative attributes of the software. • Metrics are the measuring units

35. Metrics • Quantifiable measures that could be used to measure characteristics of a software system or the software development process • Required in all phases • Required for effective management • Managers need quantifiable information, and not subjective information • Subjective information goes against the fundamental goal of engineering) CS 406 Testing

36. Kinds of software metrics • Product metrics • quantify characteristics of the product being developed • size, reliability • Process metrics • quantify characteristics of the process being used to develop the software • efficiency of fault detection CS 406 Testing

37. Applicability of metrics • Throughout the software process, like • effort in person-months • staff turnover • cost • Specific to a phase • LOC • # defects detected per hour of reviewing specifications CS 406 Testing

38. Metrics: planning • When can we plan the entire software project? • At the very beginning? • After a rapid prototype is made? • After the requirements phase? • After the specifications are ready? • Sometimes there is a need to do it early. CS 406 Testing

39. Planning: Cost estimation • Client wants to know: • How much will I have to pay? • Problem with • underestimation (possible loss by the developer) • overestimation (client may offer bid to someone else) • Cost • internal (salaries of personnel, overheads) • external (usually cost + profit) CS 406 Testing

40. Cost estimation • Other factors: • desperate for work - charge less • client may think low cost => low quality, so raise the amount • Too many variables • Human factors • Quality of programmers, experience • What if someone leaves midway • Size of product CS 406 Testing

41. Planning: Duration estimation • Problem with underestimation • unable to keep to schedule, leading to • loss of credibility • possible penalty clauses • Problem with overestimation • the client may go to other developers • Difficulty because of similar reasons as for cost estimation CS 406 Testing

42. Techniques of cost estimation • Take into account the following: • Skill levels of the programmers • Complexity of the project • Size of the project • Familiarity of the development team • Hardware • Availability of CASE tools • Deadline effect CS 406 Testing

43. COCOMO • COnstructive COst MOdel • Series of three models • Basic - macroestimation model • Intermediate COCOMO • Detailed - microestimation model • Estimates total effort in terms of person-months • Cost of development, management, support tasks included • Secretarial staff not included CS 406 Testing

44. What is a performance metric? • Count • Of how many times an event occurs • Duration • Of a time interval • Size • Of some parameter • A value derived from these fundamental measurements

45. Time-normalized metrics • Rate” metrics • Normalize metric to common time basis • Transactions per second • Bytes per second • (Number of events) ÷ (time interval over which events occurred) • “Throughput” • Useful for comparing measurements over different time intervals

46. Means vs. ends metrics • Means-based metrics • Measure what was done • Whether or not it was useful! • Nop instructions, multiply by zero, … • Produces unreliable metrics • Ends-based metrics • Measures progress towards a goal • Only counts what is actually accomplished

47. Requirements Engineering Tasks • Seven distinct tasks • Inception • Elicitation • Elaboration • Negotiation • Specification • Validation • Requirements Management • Some of these tasks may occur in parallel and all are adapted to the needs of the project • All strive to define what the customer wants • All serve to establish a solid foundation for the design and construction of the software

48. Elicitation Task • Eliciting requirements is difficult because of • Problems of scope in identifying the boundaries of the system or specifying too much technical detail rather than overall system objectives • Problems of understanding what is wanted, what the problem domain is, and what the computing environment can handle (Information that is believed to be "obvious" is often omitted) • Problems of volatility because the requirements change over time • Elicitation may be accomplished through two activities • Collaborative requirements gathering • Quality function deployment

49. Types of requirements • User requirements • System requirements • Functional requirements : • Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. • May state what the system should not do. • Non-functional requirements • Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. • Often apply to the system as a whole rather than individual features or services . • Domain requirements: • Constraints on the system from the domain of operation.

50. Requirements elicitation and analysis • Sometimes called requirements elicitation or requirements discovery. • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. • May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders