1. 1 Introduction to Software Engineering Lecture 1

2. 2 References Chapter 1: Introduction to Software Engineering from Object Oriented Software Engineering: Conquering Complex and Changing Systems

3. 3 Why Engineer Software ? Software are complex entities. –Several modules interact to achieve diverse objectives. –Several participants involved in the development process. –Validation and verification of software can be complex and arduous. Verification focuses on showing that the system and models comply with the specifications. Validation ensures that the system addresses client’s needs.

4. 4 Why Engineer Software ? (Contd…) Software are complex entities. –Software development process changes continuously. –Complex and imprecisely defined requirements may be understood and interpreted differently throughout the project. –Technology changes frequently. –Correct execution of software is dependent on the execution environment. Adhering to cost and time schedules of a software project has been extremely challenging.

5. 5 Why Engineer Software ? (Contd…) Engineering of high quality software requires gluing together the right off the shelf software components. Correct Specification of off the shelf software components is essential for seamless integration and optimum performance of the resulting system.

6. 6 What is Software Engineering A modeling activity –Dealing with complexity through models. –Focusing on relevant details at appropriate levels. –Several different models used to represent artifacts in the problem and solution domains. A problem solving activity –Models provide alternate solutions to the problem being investigated. –Constraints force software engineers to shortlist solution using empirical techniques.

7. 7 What is Software Engineering (Contd.) A knowledge acquisition activity –Modeling helps data collection its organisation into information and its formulation into knowledge. –A non-linear process, i.e., several models invalidated by a single finding. A rationale driven activity –Software engineering requires recording of context and rationale of choice of solutions. –Rationale information is represented as a set of models enabling software engineers to understand the implications of a proposed change.

8. 8 Models for Software Systems A model is an abstract representation of a system enabling the participants of an activity to answer questions about the system. Models are useful in dealing with systems that are too large, too small, too complicated or too expensive. During analysis, software engineers build models of the problem domain. During design, software engineers build models of the solution domain.

9. 9 Engg Development Vs. Software Engg Engineering Development Software Engineering Problem FormulationRequirements Elicitation Problem AnalysisSystem Analysis Solution SearchSystem Design Decision on Appropriate Solution Detailed Design Solution SpecificationImplementation Reviews

10. 10 Challenges in Engineering Software Assumptions change frequently. Solution domain remains in a constant state of flux. –Bugs –Faults –Misinterpreted requirements –Enhancements Changes force the formulation of new functional and non-functional requirements.

11. 11 Challenges in Engineering Software (Contd.) Capturing and assessing rationale is non-trivial –One decision may be based on several alternatives. –Rationale information is not explicit. –Developers commonly use intuition and experience for guidance.

12. 12 Terminologies Model –An abstraction of a real system. Activity –A set of tasks performed towards a specific purpose. Task –An atomic unit of work that can be managed. –Tasks consume resources, generate work products and depend upon work products produced by other tasks.

13. 13 Terminologies (Contd.) Resources –Assets used to accomplish work. –In a typical development project, a manager breaks down work into tasks and assigns resources for their completion. Work Product –An artifact produced during development. –Work products can be produced for other developers or for clients. Internal Work Product –Work product developed for internal consumption.

14. 14 Terminologies (Contd.) Deliverables –Work products developed for a client. –Defined prior to the start of the project and specified by a contract binding developers to the clients. Goals –High level principles used to guide a project. –Goals specify important attributes of the system. Requirements –Features that a system must possess. Functional Requirements –An area of functionality that a system must support.

15. 15 Terminologies (Contd.) Non-functional Requirements –Constraints on the operation of the system. Notation –A graphical or textual set of rules for representing a model. Method –A repeatable technique for solving a specific problem. Methodology –A collection of methods for solving a class of problems.

16. 16 Software Development Activities Requirements Elicitation Analysis Design Implementation Test Production and Maintenance

17. 17 Requirements Elicitation Objective is to provide a statement expressed in business terms defining and describing the problem domain. Involves the process of modeling a business process to describe its future business structure and functions. Static descriptions can be enhanced by dynamic simulations. Information presented during the requirements phase is expanded to provide a complete definition of the problem domain.

18. 18 Requirements Elicitation (Contd.) Outputs of the requirements phase include –Functional and process decomposition description, –Logical data models, –Usage and responsibility matrices, –Property descriptions. Decomposition of process information describes the business process steps or stages. Logical data models define the data requirements of the problem domain.

19. 19 Requirements Elicitation (Contd.) Normalisation of data models groups related facts into common entities and removes duplicate definitions. Usage and responsibility matrices show relationship between processes, entities, business goals and critical success factors. Requirements elicitation produces a record of the business in terms process, information and business rules.

20. 20 Requirements Elicitation (Contd.) Requirements Elicitations Processes Information (Data) Rules Requirements Specifications

21. 21 Analysis Analysis phase analyses the business requirements. Several modeling techniques can be used. –Entity-Relationship (ER) modeling used to describe data structures. –Data flow diagrams (DFD) used to describe the major functions in the system. –State transition diagrams (STD) describe the dynamics in real time systems. –Object oriented models describe objects in the problem domain, their attributes, their relationships and their dynamics.

22. 22 Design Process of defining the software to implement the application. Specification of the computer related aspects of the application, –Screen designs –Report designs –Logical and physical database structures –Data view for application programs –Pseudo-code and mini-specifications for program modules –Communications and integration considerations Prototyping and simulations used to refine these aspects in collaboration with users or domain experts

23. 23 Implement and Produce Emphasis on implementation and coding. Objective is to transform the output of analysis and design phases into the input required to build an industrial strength application. Automatic code generation. Languages –Procedural languages –Object oriented languages

24. 24 Testing Develop testing strategies. Use test data to test the functionality of the software. Test software in simulated environments. Test software in real environments.

25. 25 Production and Maintenance Release software for deployment. Monitor operation in warranty period to detect faults and bugs. Accommodate changing requirements. Provide functional enhancements.