![Software Engineering
• Definition[IEEE] : 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.](https://image.slidesharecdn.com/introductionsoftwareengg-141017225431-conversion-gate02/85/INTRODUCTION-TO-SOFTWARE-ENGINEERING-17-320.jpg)
INTRODUCTION TO SOFTWARE ENGINEERING
- 1. IInnttrroodduuccttiioonn ttoo SSooffttwwaarree EEnnggiinneeeerriinngg ((UUnniitt 11)) Preeti Mishra Course Incharge
- 2. The Details • Software – Evolving Role – Characteristics – Categories and Legacy Softwares – Software Myths • Project Management • Project Estimation
- 3. Software • Computer programs or the non tangible components of computer • A software is made up of: • Instruction • Data Structure • Documentation A software is developed or engineered it is not manufactured
- 4. Evolving Role of Software First Era - Limited distribution - Batch Oriented - custom software Third Era - Distributed system - Embedded system - Consumer impact Second Era - Multiuser - Realtime - Database - Product software Fourth Era - Powerful desktop PC system - Object oriented technology - Artificial Neural Network - Parallel Computing
- 5. Characteristics of a Software
- 6. Operational Characteristics • Correctness • Usability • Integrity • Efficiency • Reliability • Security • Safety
- 7. Revision Characteristics • Maintainability • Flexibility • Extensibility • Scalability • Testability • Moodularity
- 8. Transitional Characteristics • Interoperability • Reusability • Portability
- 9. Categories of Computer software • System software • Application software • Engineering/ Scientific software • Embedded software • Web-applications • Artificial intelligence software • Ubiquitous computing • Netsourcing
- 10. Legacy Software • They were developed decades ago and have been continually modified to meet changes in business requirements and computing platforms • Proliferation of such systems is causing headaches for large organization- as they are costly to maintain and risky to evolve
- 11. Why legacy systems need to evolve over time?? • To meet needs of new computing environment • To implement new business requirements • To make it interoperable with more modern systems or databases • Make it viable within a network environment
- 12. Software Myths • ``Misleading attitudes that have caused serious problems.'' are Myths • A number of common beliefs or myths that software managers, customers, and developers believe falsely.
- 13. Myths occur at Different Levels • Software Management Myths • Software Customer Myths • Developer Myths
- 14. Software Management Myths • Development problems can be solved by developing and documenting standards • Development problems can be solved by using state-of-the art tools. • When schedules slip, just add more people
- 15. Software Customer Myths • Change is easily accommodated, since software is malleable • A general statement of need is sufficient to start coding
- 16. Developer Myths • The job is done when the code is delivered • Project success depends solely on the quality of the delivered program. • You can't assess software quality until the program is running.
- 17. Software Engineering • Definition[IEEE] : 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.
- 18. Project Management • A project is a : – temporary endeavour designed to produce a unique product, service or result – with a -defined beginning and end, – undertaken to meet unique goals and objectives, typically to – bring about beneficial change or added value.
- 19. Project Management • Project management is the process and activity of – planning, – organizing, – motivating, – controlling • resources, • procedures • protocols – to achieve specific goals in scientific or daily problems
- 21. Constraints in Project Management
- 22. Generic View of software Engineering
- 23. Definition Phase In "Definition Phase", the focus is on "What” • What information is to be processed? • What performance and • Functions are required? • What system behaviour can be expected? • What interfaces to be established? • What Design Constraints exists? • What validation criteria is required? • What are the key requirements.
- 24. Development Phase In "Development Phase", focus is kept on "How” • How data are to bt structured? • How functions are to be implemented? • How procedural details are to be implemented? • How interfaces are to be categorized? • How design will be translated into programming languages? • How testing will be performed?
- 25. Maintenance Phase In "Maintenance Phase", the software is maintained to meet the future requirements • Corrective Maintenance • Adaptive Maintenance • Perfective Maintenance • Preventive Maintenance
- 26. Thus the generic process framework activities • Communication • Planning • Modeling • Construction • Deployment
- 27. Additional Activities in Generic Process Model • Project Tracking and control • Risk management • Formal technical review • Quality assurance • Measurement • Configuration management • Reusability • Work product preparation and production
- 28. Project Estimation • In project management , accurate estimates are the basis of sound project planning • “The single most important task of a project: setting realistic expectations • Unrealistic expectations based on inaccurate estimates are the single largest cause of software failure.”
- 29. Problems with Project Estimation • Predicting software cost • Predicting software schedule • Controlling software risk • Managing/tracking project as it progresses
- 30. Top-down and bottom-up estimation • Top-down – Start at the system level and assess the overall system functionality and how this is delivered through sub-systems. • Bottom-up – Start at the component level and estimate the effort required for each component. Add these efforts to reach a final estimate.
- 31. Top-down estimation – Usable without knowledge of the system architecture and the components that might be part of the system. – Takes into account costs such as integration, configuration management and documentation. – Problem: • Can underestimate the cost of solving difficult low-level technical problems.
- 32. Bottom-up estimation – Usable when the architecture of the system is known and components identified. – This can be an accurate method if the system has been designed in detail. – Problems: • It may underestimate the costs of system level activities such as integration and documentation.
- 35. References • Software Engineering: A practitioner’s approach By Roger S. Pressman • Software Engineering By Sommerville
- 36. EEnndd OOff UUnniitt 11