Software Engineering Fundamentals
Download as PPT, PDF7 likes11,106 views
This document provides an overview of software engineering. It defines software engineering as a systematic approach to software analysis, design, implementation, and maintenance. It describes conventional software engineering methods including requirements analysis, design, construction, testing, and maintenance. It also covers software project management principles, quality assurance, metrics, estimation, risk management, and testing. The document is a comprehensive introduction to the key concepts and processes in software engineering.
![3. Software Quality
Conformance to explicit and implicit
customer requirements
Striving for excellence in reliability and
functions by continuous [process]
improvement, supported by statistical
analysis of the causes of failure.](https://image.slidesharecdn.com/softwareengineeringfundamentals-131012123717-phpapp01/85/Software-Engineering-Fundamentals-35-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (9)
Ad
Similar to Software Engineering Fundamentals (20)
Ad
More from Rahul Sudame (15)
Recently uploaded (20)
Software Engineering Fundamentals
- 2. Definition Software: The programs, routines and symbolic language that controls the functioning of the hardware and direct its operation. Engineering: The application of scientific and mathematical principals to practical ands such as the design, manufacture & operation of efficient and economical structures, machines, processes and systems.
- 3. Definition Software Engineering: A systematic approach to the analysis, design, implementation and maintenance of software.
- 4. 1. Conventional Methods of SE Analysis Concepts and Principals Analysis Modeling Design Concepts and Principals Architectural Design User Interface Design
- 6. Analysis concepts and Principals Understand the Information domain of the problem Define the functionalities of the S/W Represent the behavior of the S/W Partition the models that models that depict information, function and behavior
- 7. Analysis Procedure Requirements Collection Customer Communication (Questionnaire, Interviews etc.) Modeling Partitioning Prototyping Requirements Specification
- 8. Analysis Modeling Data Object Description ER Diagram Data Flow Diagram Data Dictionary State Transition Diagram Behavior/Control Specification Process/Function Specification
- 9. Design Concepts & Principals Data Design Architectural Design Relationship among structural elements Interface Design Data Structures Human-Computer interaction Procedural Design Procedural description of S/W components
- 10. 2. Software Project Management Four P’s of Project Management People Product Process Project
- 11. Project Management… People must be organized into effective terms, motivated to do high-quality s/w work and coordinated to do effective communication. The Product requirements must be communicated from customer to developer, partitioned into their constituent parts and positioned for work by the software team.
- 12. Project Management… The Process must be adapted to the people and the problem The Project must be organized in a manner that enables the software team to succeed. The Project Management also includes Measurement and metrics estimation, risk analysis, schedules, tacking and control.
- 13. Metrics Measurement enables to improve the software process, assist in planning, tracking and control of a software project and assess the quality of the product that is produced. Measures of specific attributes of the process, project and product are used to compute S/W metrics.
- 14. Metrics… Metrics is a quantitative measure of the degree to which a system, component or process posses a given attribute.
- 15. Metrics Types Size Oriented Metrics (LOC) Function Oriented Metrics (FP) Use Case Oriented Metrics (Use Cases)
- 17. Estimation fundamentals NO zone Know zone Actual reqmts Requirement clarity • Accelerate progress into KNOW zone • Advanced requirements gathering tech • Approximate NO zone with risk
- 18. Estimation inputs High quality requirements Historical productivity rates LOC/hr, FP/hr, Pgms/day Application attributes Project team experience PM experience Language used Methodology used Platform Code complexity
- 19. Estimation inputs... Cost data S/w cost H/w cost Service charge Salaries Link Miscellaneous - travel, team meet expenses etc,.
- 20. Estimating process Identify the solution offerring - Organization std process DB 5% Freeze inventory and deliverables 50% Alternative implementation techniques - build, buy, outsource, tool based 10% Gather other estimation inputs 20% Perform estimate - Excel 10% Create schedule - res, onsite/offshore 2% Estimate the cost in $ 3%
- 23. Estimation - Metrics Productivity : size/hrs Quality Product - achieve funct & tech requirements Process - defect removal rate, measures Cost: price/prj.unit size Customer satisfaction – prj time based review
- 24. Estimation Options Delay Estimates Depends on Similar Projects Decomposition Techniques Empirical models
- 25. Estimation Decomposition Techniques Software sizing Function point sizing Standard component sizing
- 26. Estimation Problem based Estimation LOC- based Estimation FP- based Estimation Process- based Estimation
- 27. Estimation Empirical Models LOC- oriented estimation models E = 5.2*(KLOC)0.91 Walton-Felix Model E = 5.5+.73*(KLOC)1.16 Bailey-Basali Model E = 3.2+(KLOC)1.05 Boehm simple Model E = 5.288+(KLOC)1.047 Doty Model for KLOC >9 E is effort in person months
- 28. Estimation Timeline Chart Work tasks 1.1 Identify Need xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx milestone 1.2Define desired---- Week1 D1 D2 D3 D4 D5 Week2 D1 D2 Week3 D3 D4 D5
- 29. Tracking Work Tasks 1.1 Identify Need xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx milestone 1.2Define desired----- Project Table Planned Start Wk1 d1 Actual Start Wk1 d1 Planned Complete Wk1 d2 Actual Complete Assigned Effort Person Allocated Notes
- 30. Estimation Project Plan 1 Introduction 2 Project Estimate 3 Risk Management Strategy 4 Schedule 5 Project Resources 6 Staff Organization 7 Tracking and Control Management 8 Appendices
- 31. Risk Management What can go wrong ? What is the likelihood (Probability) ? What will the damage be (Impact) ? What can we do about it ?
- 32. Reactive Rick Management Project team reacts to risks when they occur Mitigation – plan for additional resources in anticipation of fire fighting Fix on failure - resources are found and applied when the risk strikes Crisis management - failure does not respond to applied resources and project is in jeopardy
- 33. Proactive Risk Management Formal risk analysis is performed Organization corrects the root causes of risk TQM concepts and statistical SQA Examining risk cources that lie beyond the bounds of the s/w Developing the skill to manage change
- 35. 3. Software Quality Conformance to explicit and implicit customer requirements Striving for excellence in reliability and functions by continuous [process] improvement, supported by statistical analysis of the causes of failure.
- 36. Measuring S/W Quality + = No. of errors & defects, severity, type, cause, effort to correct Design measures, Complexity, structure, flow Defect removal efficiency, statistical SQA data, design quality metrics
- 37. A Quality Metric E = total errors found before delivery D = total defects found after delivery Defect removal efficiency (DRE) = E / (E+D)
- 38. Software Quality S/w Quality is achieved through a disciplined approach called Software Engineering S/w Quality can be defined, described, and measured. S/w Quality can be assessed before any code has been written S/w Quality cannot be tested into a product
- 39. Software Quality Assurance SQA Goals: To improve s/w quality by monitoring both the process and the product To ensure compliance with all local standards for software engineering O ensure that any product defect, process variance or standards noncompliance is noted and fixed
- 40. Formal Technical Reviews A meeting conducted by technical people for technical people A technical assessment of a work product created during the s/w engineering process A S/w Quality Assurance mechanism A training ground
- 41. Review Process Establish Review Guidelines The review meeting Review reporting and record keeping
- 43. What is Software Testing? Any activity aimed at evaluating an attribute or capability of a program or system, to verify that it meets its required results. It is the process of executing software in a controlled manner. Testing is the process of executing a program with an intent to find errors. A process of verification and validation.
- 44. IEEE-Definition of Testing “The process of exercising or evaluating a system by manual or automatic means to verify that it satisfies specified requirements or to identify differences between expected and actual results.”
- 45. Steps in Testing Determine the goals and what is to be measured in the test Satisfy the Requirements Reliability Decide how to test Inspections walkthrough manual automation
- 46. Steps in Testing (contd...) Develop test plans and test cases Determine the expected results Execute the test cases Compare the results
- 47. Levels in Software Testing Unit Testing Individual units are tested Confirms the module is coded correctly Types are Black Box testing & White Box testing Integration Testing Test the sub systems and modules and its interfaces Checks if they function properly and meet the system requirements.
- 48. Levels in SoftwareTesting System Testing Black box Testing. Entire system is tested as an entity. User Acceptance Testing Testing the finished product with respect to the user perception.
- 49. Points to remember while Testing Testing is the process of executing a program to find an error. It is impossible to test any module or system completely. There are practical and theoretical limitations. Correcting an error can introduce another error. Testing can prevent errors. Find them early. Testing is best done by independent testers. Generally the person who codes the module carries out the Unit Testing
- 50. Why is Testing required? General Business Developers are not infallible Requirement implications are not seen Find the bugs and limitations Post release debugging is too expensive Reputation,sales,operations all affected Hazardous bugs(life/property) Professional Test case design challenging, rewarding Good testing gives confidence in work Systematic test is effective
- 51. Definitions Bug/Defect Validation Deviation from specification or standard Anything that causes customer dissatisfaction Test phase of life cycle. It is the process of checking if what has been specified, is what the user actually wanted. Verification Quality control activity. It is the checking or testing of items, including software, for conformance and consistency with an associated specification.