Software Engineering

1. Software Engineering Introduction to Software engineering 2.Software Estimation: Size, Effort and Cost 3. Software Risk Management Text PPts SEPPT2

2. Chapter 1 • Introduction to Software Engineering

3. Software • Software is defined as a set of instructions to acquire inputs and to manipulate them to produce the desired output in terms of functions and performance as determined by the user 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. Quality Attributes • The quality attributes are • • Bug free Reliable execution • • Produces correct results • • Has Reusable Structure • • Easy to maintain • • Efficient use of Computing re-sources • • Easy to understand • • User friendly.

5. Attributes of good software • Maintainability The ease of maintenance of software is very important and critical to both the software engineer and its user. If the changes are not quickly effected, the execution of business process will be disturbed. • For all changes desired by the customer or user, the software engineer has to respond very fast. • Both these requirements can be fulfilled effectively only if the software design and its architecture are so chosen that changes can be carried out in the shortest time, without affecting overall integrity of the software. • The change could be to correct mistakes, to expand its scope or adapt it to new technology. • Ease of maintenance is therefore an essential attribute of good software

6. Attributes of good software • Dependability: Dependability is the result of a number of sub-attributes, namely: reliability through assured performance, fully verified and validated processes for all functionalities and features, secured and safe to work in all eventualities of hold-up, breakdown and power crisis. • It is dependable in all conditions and situations

7. Attributes of good software • Efficiency The software is termed good if it uses the resources at its command in the most effective manner. • The resources are memory, processor and storage. The software design and architecture should be such that it offers a quick response in the least processing time, using resources at optimum level.

8. Attributes of good software • Usability: Software becomes usable if it does not call for extra effort to learn. Usability increases with good documentation. • In software operations a lot depends on the design of the user interface and the quality of the user manual.

9. Types of software • Artificial Intelligence (AI) Software • Embedded Software • Design/Engineering/Scientific Software • Business Software

10. IEEE Definition • The IEEE (Institute of Electrical and Electronics Engineers) defines SE as the application of a systematic,disciplined, quantifiable approach to the development, operations and maintenance of software. .

11. Software Engineering • Software engineering is defined as a discipline that addresses the following aspects of the software and its development. The aspects are • • Economic: Cost, Benefits, Return on Investment • • Design: Ease of development and ensuring delivery of customer requirements • • Maintenance: Ease of effecting changes and modifications • • Implementation: Ease of Installation, Demonstration, and Implementation of software by the customer and users.

12. SE scope • SE scope encompasses, broadly, eight phases as under: • Requirements study and definition for determining software scope • Requirements analysis to generate software specifi cations • Software design to deliver various components and specifi cations • Software development integration and testing & Implementation • Maintenance of software (corrective, enhancement, adaptive

13. SE Activities • Software Engineering executes a set of activities mandatory for good software development. The lead activities are • • Requirement analysis and definition and description • • Software scoping and determining its boundaries • • Factoring software in different components and configurations for development, testing and integration • • Planning, scheduling, executing, monitoring and control of software development • • Testing at all stages and phases in development for quality assurance • • Documenting the software for its users • • Implementation through demonstration, installation and execution at customer’s site • • Change management in pre- and post-implementation phase.

14. The managerial activities • The managerial activities that contribute to the efficiency and effectiveness of the software are • • Resource and effort estimation, and its management • • Risk assessment and its management • • Development process management to remain within cost, time and budget • • Project management for achieving software goals.

15. Software Engineer’s basic Skills • • Analysis and modeling abilities • • Conceptualize a software solution and support it by design • • Software development skills using tools, techniques and technologies • • Strategizing skills to evolve development, testing and implementation strategies.

16. Knowledge, Technology & communication skills SE effort is productive when the software engineer has • Domain knowledge of the Software System • Project Management skills • Higher level Communication skills and leadership qualities • Essential Technology and language skills.

17. Challenges to SE • The challenges are many as mentioned here under: • Integrating the new software in legacy systems which are stabilized and run on an old platform and technology • Integration without disturbance to current business operations, and not at extra cost • Ensuring that heterogeneous systems developed over a period of time work together effectively with new software implementation • Handling issues of data migration, system interfacing, interoperability, up gradation of technology and so on without loss of system integrity • Need to continuously upgrade that is a result of continuous improvement in technology, having a direct bearing on the cost and efficiency of the system and software

18. Steps in SE Methods • The SEM steps are as under: • Define the objective of the system • Define the boundaries of the system • Break the system into different components for understanding the system functions and features • Understand the relationships between various components • Define the relationship in terms of inputs, outputs and processes • Understand and ascertain the role of hardware and software. Also understand the role of databases and any other software products used in the system • Identify key operational and functional requirements of the system to be addressed • Model the system for analysis and development through modeling software • Discuss the systems with the customer, the users and other stakeholders affected by the system.

19. Software Development Engineering • The development engineering steps are: • • Requirement definition and specifications • • Design solution to deliver the requirement • • Determine the architecture for delivery of the solution • • Software development planning • • Software testing by components • • Integration of system components • • Integration testing for confirmation and conformance of delivery of requirements • • Determination of implementation strategy • • Implementation • • Change management process • • Maintenance of the installed software.

20. ‘Waterfall Model’ • The development engineering model generally followed is the ‘Waterfall Model’ when following conditions prevail: • Requirement analysis and definition 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 a change due to changes in technology, platform and language considered in the system. • The system is so well understood by users that changes are not expected during the operations and maintenance. • The legacy systems like Accounting, Payroll and Manufacturing belong to this category. ‘

21. Evolutionary model • When user requirements are abstract in terms of problems and desired software solution and there is a difference in opinion on how to go about developing a software solution, the life cycle process model is evolutionary (iterative). • This model prescribes evolutionary approach to development. In this approach, software is • evolved using standard development steps in stages in a repetitive manner. • Evolution and iteration continues till the abstract nature of the problem is removed and a firm software solution is developed. • In development steps prototyping, risk analysis, proving the concepts are performed to eradicate the abstract nature of the requirement and the solution. Since development progresses in steps to complete the requirement, several iterations are required to evolve complete solution.

22. CMM • CMM-Level-1: Initial, undefined and chaotic. • CMM-Level-2: Repeatable stable performance, basic project management processes are in use. • CMM-Level-3: Defined. In addition to level-2 activities, the organization has defined processes, and management activities are documented and integrated into the organization's processes supporting level-2 activities. • Both engineering and management activities are documented and integrated in the organization's processes. • CMM-Level-4: Managed through setting standards, and standards are built for organization. Data on software metrics and quality is collected for building standards. • CMM-Level-5: Learning organization using knowledge databases. Leveraging on knowledge and innovative ideas

23. Software Development Process Models • Linear Sequential Model (LSM) • The Prototype Model (PRM) • The Rapid Application Development Model (RAD) • The Incremental Model (INM) • The Boehm Spiral Model (BSM) • In all models, core activities, namely, Analysis—Design—Code —Test are common. However, their execution differs from model to model.

24. Wasserman 7 Principles • That have altered software engineering practices. • 1. Criticality of time to deliver. • 2. Change in software development economics, i.e. shift from higher hardware cost to lower hardware cost, indicating lower power performance versus cost ratio. • 3. Change in computing culture: centrally controlled main/mini platform to distributed client server user driven desktop computing. • 4. Computing focus shift from local to wide area networks. use of Internet and Web technologies. • 5. Paradigm shift in development strategy, shift from SSAD to OOSAD technology. • 6. Design and architecture style based on user behavior using use cases and unified modeling language. • 7. Very rare use of waterfall model due to its inherent rigid approach to development and shift to Boehm’s spiral model with iterative evolution approach to development.

25. Wasserman 5 ways of decomposing the system • 1. Modular Function is a module. Sub-function is a sub-module. • 2. External data driven Data structure, basis for decomposition. That is, use of data hierarchy constructed by type and application or usage. • 3. Event driven Event-responding decomposition Event could be external or internal. For example, ATM Card swapping will trigger an event. Receipt of material is an event generating receipt processing. • 4. User inputs driven Wasserman calls it ‘outside-in design’. Decomposition is built on the basis of user inputs to the system. For example, at the billing counter in a shop, the package is scanned. A unit is needed to receive it and process it. • 5. Class-object driven Viewing the system in class and objects and their relationship.

26. Chapter 2 Software Estimation: Size, Effort and Cost

27. Software Metrics • Software Metrics can be used to indicate the basic attributes of the software. The indicative metrics, not exhaustive, are • Size: Line of Code, Function Point Count • Quality: Reliability, Accuracy, Dependability, and these are measured through some measures like errors, failures and number of runs between failures, etc. • Execution time: Process time of execution of a critical process and many more.

28. Baseline data for project metrics • Duration, Efforts, Cost • Function Points • Lines of Code • Pages in Documentation • Reviews

29. Indirect Measures of Software quality The ISO 9126 standards is an attempt to identify the key quality attributes for computer software. The standard identifies six key quality attributes as under. • Functionality • Reliability • Usability • Efficiency • Maintainability • Portability on different platforms All the six key attributes form a basis for indirect measures for assessing the quality of a software system.

30. FPA • IFPUG has set the objectives for FPA. These are • Measure functionality of software from a user’s perspective. • Measure the functionality independent of development and implementation technology. • Create simple and consistent measures to estimate the size of the software across projects and organizations. • Use Function Point Analysis (FPA) Method.

31. FPA method • FPA method is simple to follow. It begins with determining users’ requirement from software. First step in the method is to determine the following on the basis of requirement analysis and software requirement specification (SRS). • Identify the boundaries of the software scope. • Count all functional requirements. • Count all non-functional requirements. • Identify design constraints.

32. Software Rating on General System 14 Characteristics • Data Communications • • Distributed Processing • • Performance • Transaction Rate • • On-line Data Entry • • End-User Efficiency • • On-line Update • • Processing • • Reusability • • Installation • • Operations • • Multiple Sites • • Change Requirement These characteristics have an effect on design, development, architecture and implementation that require specific skills and resources. The value arrived at after consideration of these characteristics will change the UFP count• These characteristics have an effect on design, development, architecture and implementation that require specific skills and resources. The value arrived at after consideration of these characteristics will change the UFP count

33. Advantages & disadvantages of FPA • Advantages • The advantages of FPC are due to the basis of its computation: • FPC is independent of the technology, that is, OS, programming language, database, developer productivity and methodology. • The FPC concept is simple to understand; hence, it becomes a good quick measure for any comparative analysis. Companies use FPCs to compare between software, or between the productivity of different groups. • Disadvantages • Estimation is based on the subjective judgment of the software designer. It therefore varies from person to person; the choice of design and architecture is also subjective. • Since the software system is decomposed in various components, and then into data and functions, the estimate does not cater to integration requirement of these components. It therefore needs subjective adjustment to arrive at the FPC for the whole software system. • The system may have more than 14 characteristics that have not been considered. • The internal processing complexity due to the use of complex business rules, algorithms, calculations etc is not weighed adequately.

34. COCOMO • COCOMO (COnstructive COst MOdel) considers the size of the software and several other characteristics of the proposed software. Dr. Barry Boehm in 1981 proposed this approach when software engineers started using OOD, component technologies, reusable strategies, and automated tools for code generation, testing and so on. • A series of mathematical formulae are used to predict effort based on software size (FPC) and other factors such as maturity of process and capability of development team, development flexibility, risk and risk resolution. • The COCOMO model uses exponential component in estimation. This is mainly because efforts do not normally increase linearly with size.

35. COCOMO II • The latest version of the COCOMO model is COCOMO II, released in 1997. This model uses 161 data points, and uses Bayesian statistical analysis of empirical data on completed projects and expert opinions. • COCOMO II has three estimation models to estimate effort and cost. The models are Application Suite, Early Design and Final Design Architectural Model.

36. SOFTWARE COST ESTIMATION • Once the size of the software (FPC or LoC) is estimated, the next important parameter is the cost of development. • The costs to be considered are as under: • Personnel costs • Hardware costs • Software costs • Communication, travel and stay costs. • Training costs. • Outsourcing costs. • Marketing costs • Administrative costs.

37. Chapter 3 Risk Management

38. Risk Management • Risk Management (RM) is a process made up of the following steps: • risk identification, • risk analysis, • risk assessment, • risk planning, • risk monitoring • and risk mitigation.

39. Types of Risk • Software Process Risks include managerial and technical procedures required to be undertaken for software development. Managerial processes include activities like planning, staffing, monitoring, quality assurance and control. In technical procedures, software engineering activities such as requirement analysis, design code and test are included. • Process risk occurs due to uncertainties involved in assessing, estimating various inputs to the software process. There are uncertainties in resource availability, quality specifications from the customer and so on. • In technical procedures, uncertainty may be on account of the customer not being able to confirm in precise terms the software requirement specifications, or uncertainty about platform, its capability and configuration and so on. Such uncertainties affect quality, efforts, cost and schedule enhancing the business risk.

40. Types of Risk • Software Project Risk arises on account of operational, organizational and contractual software development factors. This risk occurs due to conditions and constraints about resources, relationship with vendors and contractors, unreliable vendors and lack of organizational support. • Funding is the significant project risk the management has to face. It occurs due to initial budgeting constraints and unreliable customer payments.

41. Types of Risk • Software Product Risk mainly concerns the quality characteristics of the software product. This originates from the conditions such as unstable requirement specifications, not being able to meet the design specifications affecting software performance and uncertain test specifications. • In view of the software product risk, there is a risk of losing the business and facing strained customer relations.

42. Nature of risk • Technology Risks (Unpredictable) These risks fall in the domain of hardware, software and network communication technology, which are subject to continuous improvement and may lead to obsolescence. • People Risks (Known) These risks are associated with persons in the teams and risk concerns availability, capability, skills, maturity and so on. • Organizational Risks (Predictable) These are in the area of development organization and customer organization. The environment in both the organizations is a matter of concern. • • Requirement Risks (Known) This is about clarity, completeness and confirmation of the requirement by the end users and customer. It is about the volatility of the requirement. • Estimation Risks (Known)

43. Risk Type & % of incidence • Technology: 5 to 10 % • People: 20%. • Organization: 20% • Requirements: 60%. • Estimation of efforts & resources: 30%

44. Risk Analysis & Exposure • Risk Analysis (RA) is a process that defines activities and methods to estimate and evaluate risk. • In estimation, the probability of occurrence is estimated and its consequence. • In evaluation, the risk options against certain criteria are discussed. • The risk analysis process begins with list of risks obtained from the earlier process of risk identification. • Each risk from this list is taken for estimation and evaluation. To act on this step, the organization needs an evaluation criteria and the risk database. First, the probability and consequence is estimated and then the • Risk Exposure (RE) determined. • Risk Exposure = Probability x Loss

45. Risk Action Plan (RAP). • Plan Risk Resolution Strategy • The risk plan proposes various actions to deal with the risks identified and analyzed in the earlier processes. • The output of the process is the Risk Action Plan (RAP). • RAP takes as input the Prioritized Risk List based on risk severity, and determines resolution strategies for each one on the list. The risk resolution strategies suggested by Ellan H. Hall a researcher and author of the book on Risk management are • Risk Acceptance • Risk Reduction • Risk Protection • Risk Transfer • Risk Reserves • Risk Research • Risk Avoidance

46. RM Process • Identify Risk • Analyze Risk • Plan for Risk resolution • Track Risk • Resolve Risk

47. Risk Mitigation Planning • Prepare a prioritized risk list based on risk exposure and its severity index. • Determine risk resolution strategy for each. • Design an action plan based on resolution strategy to deal with risk. • Institute a monitoring plan through systematic review, and MIS reports on risks integrated into MIS reports. • Take corrective measures to control the impact.

48. RMMM Plan Document • The RMMM plan document has following structure: • 1. Software project name/ID/details • 2. Project scope details. • 3. Software Details on customer, end users and the development environment. • 4. Risk statement with context • 5. Responsibilities by risk type and assignment • Management • Operational• Technical • 6. Risk Table with priorities and strategies for resolution. • 7. Action plans by risk and review framework. • 8. Expected Impact, monitoring steps and stages. • 9. RMMM plan review schedule. • 10. Post-implementation risk database updates. • 11. Post-implementation comparative analysis of risk impact on cost, schedule, effort, scope and quality.