SEPPT1 Software Engineering 20 sessions Program In SE 304 PPTs*.

1. SEPPT1Software Engineering20 sessions Program In SE304 PPTs*. Waman Jawadekar Jawadekar@vsnl.com (M)98508 36537 Not to be used without permission Of McGraw Hill . Reproduction is not permitted.

2. Session 1 • Introduction to SE • Learning objective: • Understanding Software. • Engineering approach to Software Development. • Attributes of good software • Types of software • Definition and scope of SE • SE activities.

3. Definition of software : • Software is a set of instructions to acquire inputs to manipulate to produce the desired output in terms of functions and performance as determined by the users of the software. • It also includes a set of documents, such as the software manual, meant for users to understand the software system. • Today’s software comprises the Source Code, Executables, Design Documents, Operations and System Manuals, and Installation and Implementation Manuals.

4. How to describe a Software? • A software is described by its capabilities. • The capabilities relate to • the Functions, it executes, the Features, it provides, the Facilities, it offers the Platforms it supports.

5. Bug free • Reliable • Produces correct results • Reusable Structure. • Easy to maintain • Easy to Understand • Efficient use of Computing resources • User friendly. Technical Attributes of Good Software • Attributes

6. Quality attributes of Good software • Quality Attributes: They score high on • Maintainable: Easy to Change or Modify • Dependable: Always available & gives correct Results • Efficient: Cost effective • Usability: Ease of use • User Acceptance: Very High: Commercial & operational

7. What assures ‘Dependability’ ? • Availability: Ability to deliver when called for. • Reliability:Ability to deliver as per RDD specification. • Safety:Ability to operate without damage • Security:Ability to protect itself from external or internal threats. • Dependability is extremely important in case of Critical systems.

8. Type of Software • Type: • System software, • Business software, • Design and scientific software, • Embedded software, • Intelligent software • Software:Product or Package or Tool or Solution ( Customized Product developed for solving customer specific problem)

9. When software is not dependable? When software • is bug ridden, ( Fails to run or operate) • has mistakes, (Misrepresents requirements) • produces errors,(Represents requirements but handles incorrectly or faulty in certain conditions.)

10. What is Software Engineering? • SE Definition • Software engineering is defined as a systematic logical approach to software development that contributes to the building of quality attributes of good software. • It is an engineering discipline because it is systematic, scientific, and methodical and uses standards, models and algorithms in design and development of the software.

11. SE scope • SE scope • Requirements study. • Requirements analysis • Solution Design • Software Design • Software Development • Testing, Verification & Validation • Integration of different components • Deployment • Implementation • Change Management • Maintenance.

12. SE approaches to Software Development • SE approaches: • Structured Systems Analysis and Design (SSAD) • Object Oriented Systems Analysis and Design (OOSAD). • SSAD: UsesStructured hierarchy of functions in modeling the System Requirements • OOSAD: Uses structured hierarchy of Objects in modeling the system Requirements

13. Developers Skills: • Developers Skills: • Analysis and modelling abilities. • Conceptual skills. • Design & Architecture skills. • Software programming skills. • Software development skills. • Development strategy skills. • Domain knowledge skill. • Application Knowledge skill. • Management skills. • Communication skills • leadership skills • Ability to work in a Team • Technology and language skills

14. Issues & Challenges In software Development • Issues & challenges: • Delivering on time as per requirements. • Developing within the budgeted cost. • Integrating the new software in legacy systems. • Integration without disturbance to current business operations. • Ensuring heterogeneous systems work together effectively. • Handling issues of data capture, migration, system interfacing, interoperability, up gradation of technology and so on without loss of system integrity. • Need to continuously upgrade and manage change dynamically.

15. Cost of Software Development • Cost of development: • Development cost = 60% • Testing cost = 40%

16. SE Development Scope. • Scope: • Define the objective of the system. • Define the boundaries of the system. • Factorise the system into different components. • Understand the relationships between various components • Identify inputs, outputs and processes in each of them. • Determine hardware ,development software and technology platform. • Identify key operational and functional requirements of software. • Discuss the systems requirement with the customer, users and other stakeholders. • Freeze the requirement. • Develop the software.

17. Knowledge of Application Domain Tools & Technology Customer Environment Development Resource Enabled by Management of Resource and Relations Influenced by Business Conditions Capability Maturity Software Product Requirements Specs. Customer Relations Areas Affecting Software & its Development • Areas: Customer, Business, Domain & Management maturity.

18. INVOICING SYSTEM Dispatch Verification Delivery Note Processing Order Status Verification Inventory Status Updating Process Sales Amount Update of Order for Dispatch Balance Process Tax Component Modify the Sales Analysis Status Invoice Processing Example: SSAD: illustration of Modeling, structuring, relations,& Interface.

19. OOSAD: Object Model: • Class: Pay order. Objects: Product Bill, Service Bill Pay order Product Bill Service Bill NO, Date Material service name From To Quantity Service rate Reference Packet No Quantity Signature Price Amount Delivery note Taxes Extract Compute Tax Compute labor Aggregate Compute Net Compute material Print Compute service Mail tax. Update

20. Session 2 • Overview of SE. • Learning Objective: • SE Components • Systems engineering • Development engineering • Approaches to development: Structured SSAD & Object OOSAD. • Understanding CMM model

21. Software Engineering (SE) Components System Engineering SE Components System Development Engineering

22. Software Engineering Components & Processes System Engineering Development Engineering BPR & Design New system . Requirement Analysis Requirement Definition Decompose The System Software specification Define the system goals & Objective Software Design Identify Key functions Software Development Identify Key Processes Test & deliver Define scope Context, Boundaries

23. Software Development Life Cycle: SDLC Model • Development moves through a life cycle. • Life cycle has following phases. Study & Analysis, Design & Architecture, Develop & Test, Deliver & Implement • The SDLC Models are, • Waterfall model • Evolutionary model • Boehm's Model • V - Model

24. Focus of SE in Software Development • Economics: Cost, Benefits and ROI. • Design & Architecture: Ease of Development and Maintenance. • Technology: Portability and Interoperability. • Environment: Business, Customer & Users

25. CMM: SEI Capability Maturity Model • Organization CMM level • CMM-Level-1: Initial: Undefined and chaotic development processes. • CMM-Level-2: Repeatable: Stable performance but no improvement, basic development processes are in use. • CMM-Level-3: DefinedProcesses: In addition to level-2 activities, the organisation has defined processes, and management activities are documented and integrated into the organisation’s processes supporting level-2 activities. Both engineering and management activities are documented and integrated in the organisation’s processes. • CMM-Level-4:Managed Performance Managed through setting standards, and standards are built for organisation. Data on software metrics and quality is collected for building standards. • CMM-Level-5: Optimum Performance Learning organisation using knowledge databases. Leveraging on knowledge and innovative ideas.

26. Performance VS CMM level:Comparison OF CMM levels CMM level

27. Session 3 • SDLC Models • Learning Objective • Understanding Waterfall, V - Model & Evolutionary Model ,Boehm’s spiral model. • When & where applicable? • Type of systems and Models

28. Generic Process Of Software Development • Generic process is linear sequential. • Requirement Elicitation • Requirement analysis • Preparing RDD & SRS Document. • Design the system • Design architecture • Develop the system as per design. • Test the system Components • Integrate components. • Install the system • Test on deployment platform • Obtain the user acceptance. This generic process is modeled into different development models.

29. SDLC Models

30. Waterfall Model • Requirement definition and description is stable, and unlikely to change in a significant way during development and in the post-implementation period. • Software system design is not likely to undergo achange due to changes in technology, platform and language considered in the system. • The system is so well understood by users that changes from them are not expected during development operations and maintenance • Risk of software development is almost nil.

31. Requirement Analysis & Definition • Requirement Analysis & Definition: • All requirements of the system which has to be developed are collected in this step. • Requirements have to be collected by analyzing the needs of the end users and checking them for validity and the possibility to implement them. • The aim is to generate a Requirements Specification Document which is used as an input for the next phase of the model.

32. System Design: • System Design: • The system has to be properly designed before any implementation is started. This involves an architectural design which defines and describes the main blocks and components of the system, their interfaces and interactions. • Then the needed hardware is defined and the software is split up in its components. E.g. this involves the definition or selection of a computer platform, an operating system, other peripheral hardware, etc. • The software components have to be defined to meet the end user requirements and to meet the need of possible scalability of the system. • The aim of this phase is to generate a System Architecture Document this serves as an input for the software design phase of the development, but also as an input for hardware design or selection activities.

33. Software Design • Software Design: • Based on the system architecture ,the software design will break them further down into code modules. • The interfaces and interactions of the modules are described, as well as their functional contents. • All necessary system states like startup, shutdown, error conditions and diagnostic modes have to be considered and the activity and behavior of the software has to be defined. • The output of this phase is a Software Design Document which is the base of the following development work.

34. Coding: • Coding: Based on the software design document the work is aiming to set up the defined modules or units and actual coding is started. • The system is first developed in smaller portions called units. They are able to stand alone from an functional aspect and are integrated later on to form the complete software package.

35. Software Integration & Verification: • Software Integration & Verification: • Each unit is developed independently and can be tested for its functionality. This is the so called Unit Testing. It simply verifies if the modules or units to check if they meet their specifications. • This involves functional tests at the interfaces of the modules, but also more detailed tests which consider the inner structure of the software modules. • During integration the units which are developed and tested for their functionalities are brought together. • The modules are integrated into a complete system and tested to check if all modules cooperate as expected.

36. System Verification: • System Verification: • After successfully integration including the related tests the complete system has to be tested against its initial requirements. • This will include the original hardware and environment, whereas the previous integration and testing phase may still be performed in a different environment or on a test bench.

37. Operation & Maintenance: • Operation & Maintenance: • The system is handed over to the customer and will be used first time by him. • Customer will check if his requirements were implemented as expected but he will also validate if the correct requirements have been set up in the beginning. • In case there are changes necessary it has to be fixed to make the system usable or to make it comply to the customer wishes. • In most of the "Waterfall Model" descriptions this phase is extended to a never ending phase of "Operations & Maintenance". • All the problems which did not arise during the previous phases will be solved in this last phase.

38. Weakness Of waterfall • IT is very important to gather all possible requirements during the first phase of requirements collection and analysis. If not all requirements are obtained at once the subsequent phases will suffer from it. • Usually only a part of the requirements is known at the beginning and a good deal will be gathered during the complete development time. • Iterations are only meant to happen within the same phase or at best from the start of the subsequent phase back to the previous phase. • Instead of solving the root causes the tendency is to patch problems with inadequate measures. • There may be a very big "Maintenance" phase at the end. The process only allows for a single run through the waterfall.

39. Evolutionary (Iterative) model • When system is new. • System & software solution needs to be conceptualized before development. • There are issues about use of technology, platform. User wants the experimentation approach to confirm RDD • Begins with prototyping, experimentation, testing at site confirming the completeness and clarity of RDD. • Use of extensive testing, reviews and inspection to confirm the rightness of the system. • Risk of software development is very high. Hence approach to software is evolutionary.

40. Evolutionary Model • In the Evolution Model, development engineering effort is made first to establish correct, precise requirement definitions and system scope to establish a ‘Base System’. • Then to the base system, few features are added progressively through evolution process. • In evolution process not only requirements are confirmed but its solution is also agreed by the users.

41. Boehm’s Spiral Model

42. Boehm’s Spiral Model Boehm’s Spiral: when system is known but. • RDD is complex, unclear in some parts. • User wants progressive development with risk assessment. • Needs development in stages one after another part by part. • Linear Sequential development for well defined part of RDD & for other evolutionary development. • Each stage is a ‘complete’ product of a limited RDD scope. • The entire scope is completed in stages with version number. • Risk of development is controlled.

43. V - Model

44. V - Model • A modification of the waterfall model, called "V-Model". • The individual steps of the process are almost the same as in the waterfall model. • However, there is one big difference. Instead of going down the waterfall in a linear way the process steps are bent upwards at the coding phase, to form the typical V shape. • The reason for this is that for each of the design phases it was found that there is a counterpart in the testing phases which correlate to each other.

45. Mandatory activities inall types of software development. • Mandatory activities • Risk analysis • Activity Planning, scheduling, tracking and control of Progress • Technical reviews of design, architecture, and program • Software quality assurance measures • Documentation of development process and that of developed software • Measurement of efforts, resources, costs and budgets for planning and building development standards

46. Class Exercise • Recommend the SDLC Model for following systems:. Waterfall/ Evolutionary/ V Model/ Boehm’s Model • Geometric software for computing Area, volume, weight of standard objects. 2. Sales Forecasting System for a Pressure cooker. • Billing & Material accounting system for a Medical shop. • Web Portal for a Holiday Resort. • RTO license processing system. • Analysis of Customer feedback.

47. Session 4 • Development Process Models • Learning Objective: • Understanding of five Development process models. • When to Use them? • Comparative analysis. • Modern Software Development

48. Activity Processes Common Activities Software Components Task Activities Work Breakdown Tasks A1 A2 A3 A4 A5 A6 Code Executable Documentation * There are ‘n’ tasks. Each task has ‘m’ activities and each activity has ‘r’ processes Plans Software System Development Process Plans Generic Process Development Model

49. Common Activities in addition to SDLC Activities • Common Activities • A1 :Planning & Control • A2 : Technical Reviews • A3 : Software Quality Assurance • A4 : Documentation • A5 : Risk Analysis • A6 : Measurement & Building Standards

50. Requirement Analysis Solution Design Code the Solution Test for Quality SDPM:Linear Sequential Model • Linear Sequential Model (LSM) Applicable when System scope is clear. Requirement is Definite, clear & complete. It is agreed by users and developers. There are no issues about technology and platforms. In brief, there is no uncertainty what so ever. A no risk scenario.