![The IEEE definition:
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.
(2) The study of approaches as in (1).
The seminal definition:
[Software engineering is] the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works
efficiently on real machines.
Software Engineering Definition](https://image.slidesharecdn.com/unit1introductiontosoftenggmbatechiiyear-150805093310-lva1-app6892/85/Unit-1-introduction-tosoftengg_mba-tech-ii-year-11-320.jpg)
![Management Myths
• We already have standards and procedures for building software;
isn’t that enough?
– How widely used is it?
– How relevant to the team?
– How useful to the project?
• If we’re behind schedule, we’ll just add more programmers to
catch up
– “Adding people to a late project makes it later” [Brooks]
– Ramp-up time
– Interference
• If I outsource a project, I can just relax
– Management issues are much more difficult, and if not
understood, will sink the project](https://image.slidesharecdn.com/unit1introductiontosoftenggmbatechiiyear-150805093310-lva1-app6892/85/Unit-1-introduction-tosoftengg_mba-tech-ii-year-26-320.jpg)
Unit 1 introduction tosoftengg_mba tech ii year
- 1. 1 Introduction to Software Engineering Preeti Mishra Course Instructor
- 2. Basics: Software & Software Engineering
- 3. What is Software? The product that software professionals build and then support over the long term. Software encompasses: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately store and manipulate information and (3) documentation that describes the operation and use of the programs.
- 4. Software products • Generic products – Stand-alone systems that are marketed and sold to any customer who wishes to buy them. – Examples – PC software such as editing, graphics programs, project management tools • Customized products – Software that is commissioned by a specific customer to meet their own needs. – Examples – embedded control systems, air traffic control software, traffic monitoring systems.
- 5. Software Categories • 1. System software: such as compilers, editors, file management utilities • 2. Application software: stand-alone programs for specific needs. • 3. Engineering/scientific software: Characterized by “number crunching”algorithms. such as automotive stress analysis, molecular biology, orbital dynamics etc • 4. Embedded software resides within a product or system. (key pad control of a microwave oven, digital function of dashboard display in a car) • 5. Product-line software focus on a limited marketplace to address mass consumer market. (word processing, graphics, database management) • 6. WebApps (Web applications) network centric software. As web 2.0 emerges, more sophisticated computing environments is supported integrated with remote database and business applications. • 7. AI software uses non-numerical algorithm to solve complex problem. Robotics, expert system, pattern recognition game playing
- 6. Software—New Categories • Open world computing—pervasive, ubiquitous, distributed computing due to wireless networking. How to allow mobile devices, personal computer, enterprise system to communicate across vast network. • Netsourcing—the Web as a computing engine. How to architect simple and sophisticated applications to target end-users worldwide. • Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) • Also … (see Chapter 31) – Data mining – Grid computing – Cognitive machines – Software for nanotechnologies
- 7. Why Software is Important? • The economies of ALL developed nations are dependent on software. • More and more systems are software controlled ( transportation, medical, telecommunications, military, industrial, entertainment,) • Software engineering is concerned with theories, methods and tools for professional software development. • Expenditure on software represents a significant fraction of GNP in all developed countries.
- 8. Software costs • Software costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost. • Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs. • Software engineering is concerned with cost-effective software development.
- 9. Features of Software? • Its characteristics that make it different from other things human being build. Features of such logical system: • Software is developed or engineered, it is not manufactured in the classical sense which has quality problem. • Software doesn't "wear out.” but it deteriorates (due to change). Hardware has bathtub curve of failure rate ( high failure rate in the beginning, then drop to steady state, then cumulative effects of dust, vibration, abuse occurs). • Although the industry is moving toward component-based construction, most software continues to be custom-built. • Modern reusable components encapsulate data and processing into software parts to be reused by different programs. E.g. graphical user interface, window, pull-down menus in library etc.
- 10. Wear vs. Deterioration 10 idealizedcurve change actualcurve Failure rate Time increasedfailure rate due toside effects
- 11. The IEEE definition: 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. (2) The study of approaches as in (1). The seminal definition: [Software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. Software Engineering Definition
- 12. Importance of Software Engineering • More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly. • It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of system, the majority of costs are the costs of changing the software after it has gone into use.
- 13. FAQ about software engineering Question Answer What is software? Computer programs, data structures and associated documentation. Software products may be developed for a particular customer or may be developed for a general market. What are the attributes of good software? Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production. What is the difference between software engineering and computer science? Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. What is the difference between software engineering and system engineering? System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process.
- 14. Essential attributes of good software Product characteristic Description Maintainability • Software should be written in such a way so that it can evolve to meet the changing needs of customers. • This is a critical attribute because software change is an inevitable requirement of a changing business environment. Dependability and security • Software dependability includes a range of characteristics including • reliability, • security and • safety. • Dependable software should not cause physical or economic damage in the event of system failure. • Malicious users should not be able to access or damage the system. Efficiency • Software should not make wasteful use of system resources such as memory and processor cycles. • Efficiency therefore includes responsiveness, processing time, memory utilisation, etc. Acceptability • Software must be acceptable to the type of users for which it is designed. • This means that it must be understandable, usable and compatible with other systems that they use.
- 16. Questions!!
- 17. Software Process
- 18. A Layered Technology aa “quality” focus“quality” focus process modelprocess model methodsmethods toolstools Any engineering approach must rest on organizational commitment to quality which fosters a continuous process improvement culture. Process Method Tools
- 19. Process, Methods, and Tools • Process – Provides the glue that holds the layers together; enables rational and timely development; provides a framework for effective delivery of technology; forms the basis for management; provides the context for technical methods, work products, milestones, quality measures, and change management • Methods – Provide the technical "how to" for building software; rely on a set of basic principles; encompass a broad array of tasks; include modeling activities • Tools – Provide automated or semi-automated support for the process and methods (i.e., CASE tools)
- 20. Process?? • (Webster) A system of operations in producing something; a series of actions, changes, or functions that achieve an end or a result • (IEEE) A sequence of steps performed for a given purpose
- 21. What is a Software Process? • (SEI) A set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products (e.g., project plans, design documents, code, test cases, and user manuals) • As an organization matures, the software process becomes better defined and more consistently implemented throughout the organization • Software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective
- 22. Five Activities of a Generic Process framework • Communication: communicate with customer to understand objectives and gather requirements • Planning: creates a “map” defines the work by describing the tasks, risks and resources, work products and work schedule. • Modeling: Create a “sketch”, what it looks like architecturally, how the constituent parts fit together and other characteristics. • Construction: code generation and the testing. • Deployment: Delivered to the customer who evaluates the products and provides feedback based on the evaluation. • These five framework activities can be used to all software development regardless of the application domain, size of the project, complexity of the efforts etc, though the details will be different in each case. • For many software projects, these framework activities are applied iteratively as a project progresses. Each iteration produces a software increment that provides a subset of overall software features and functionality.
- 23. Umbrella Activities Complement the five process framework activities and help team manage and control progress, quality, change, and risk. 1. Software project tracking and control: assess progress against the plan and take actions to maintain the schedule. 2. Risk management: assesses risks that may affect the outcome and quality. 3. Software quality assurance: defines and conduct activities to ensure quality. 4. Technical reviews: assesses work products to uncover and remove errors before going to the next activity. 5. Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs are met. 6. Software configuration management: manage the effects of change throughout the software process. 7. Reusability management: defines criteria for work product reuse and establishes mechanism to achieve reusable components. 8. Work product preparation and production: create work products such as models, documents, logs, forms and lists.
- 24. Software Myths
- 25. Software Myths Erroneous beliefs about software and the process that is used to build it. •Affect managers, customers (and other non-technical stakeholders) and practitioners •Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and methods •Poor management and technical practices, even when reality dictates a better approach.
- 26. Management Myths • We already have standards and procedures for building software; isn’t that enough? – How widely used is it? – How relevant to the team? – How useful to the project? • If we’re behind schedule, we’ll just add more programmers to catch up – “Adding people to a late project makes it later” [Brooks] – Ramp-up time – Interference • If I outsource a project, I can just relax – Management issues are much more difficult, and if not understood, will sink the project
- 27. Customer Myths • A general statement of work is sufficient to kick off the project, and we can fill in the details later • Requirements can change, and that’s OK because software is so flexible -Most software project failures can be traced to inadequacy of requirement specifications
- 28. Software Engineers’ Myths • Once the program is written, I’m done – Between 60-80% of effort expended after delivery • Until the program is written, quality is uncertain – Formal design reviews – Formal code reviews – Test-first approaches – Prototyping to verify design and structure – Prototyping to validate requirements • The only deliverable is the program itself – Lots of documentation: installation guides, usage guides, maintenance guides, API defintions and examples
- 29. Software Engineers’ Myths • Documentation is Software-Engineering busy work – Focus is on quality, not quantity – Documentation can be hard for engineers to write, just as C++ may be difficult for poets.
- 30. Legacy Software
- 31. What is Legacy System • In computing, a legacy system is an old method, technology, computer system, or application program, "of, relating to, or being a previous or outdated computer system.“ • Often a pejorative term, referencing a system as "legacy" often implies that the system is out of date or in need of replacement.
- 32. Legacy Software - Characteristics • Support core business functions • Have longevity and business criticality • Exhibit poor quality – Convoluted code, poor documentation, poor testing, poor change management
- 33. Why Organizations can have compelling reasons for keeping a legacy S/W • The system works satisfactorily, and the owner sees no reason to change it. • The costs of redesigning or replacing the system are prohibitive because it is large, monolithic, and/or complex. • Retraining on a new system would be costly in lost time and money, compared to the anticipated appreciable benefits of replacing it • The system requires near-constant availability, so it cannot be taken out of service, and the cost of designing a new system • The user expects that the system can easily be replaced when this becomes necessary. • Newer systems perform undesirable (especially for individual or non- institutional users)
- 34. Problems posed by legacy Software • If legacy software runs on only antiquated hardware, the cost of maintaining the system may eventually outweigh the cost of replacing both the software and hardware unless • These systems can be hard to maintain, improve, and expand because there is a general lack of understanding of the system; the staff who were experts on it have retired or forgotten what they knew about it, and staff who entered the field after it became "legacy" never learned about it in the first place. This can be worsened by lack or loss of documentation. • Legacy systems may have vulnerabilities in older operating systems or applications due to lack of security patches being available or applied. • Integration with newer systems may also be difficult because new software may use completely different technologies.
- 35. Reasons for Evolving the Legacy Software • (Adaptive) Must be adapted to meet the needs of new computing environments or more modern systems, databases, or networks • (Perfective) Must be enhanced to implement new business requirements • (Corrective) Must be changed because of errors found in the specification, design, or implementation
- 36. Software Project Planning The act or process of making a plan or plans.
- 37. Task Set for Project Planning 1) Establish project scope 2) Determine feasibility 3) Analyze risks 4) Define required resources a) Determine human resources required b) Define reusable software resources c) Identify environmental resources 5) Estimate cost and effort a) Decompose the problem b) Develop two or more estimates using different approaches c) Reconcile the estimates 6) Develop a project schedule a) Establish a meaningful task set b) Define a task network c) Use scheduling tools to develop a timeline chart d) Define schedule tracking mechanisms
- 38. Software Scope • Software scope describes – The functions and features that are to be delivered to end users – The data that are input to and output from the system – The "content" that is presented to users as a consequence of using the software – The performance, constraints, interfaces, and reliability that bound the system • Scope can be define using two techniques – A narrative description of software scope is developed after communication with all stakeholders – A set of use cases is developed by end users • After the scope has been identified, two questions are asked – Can we build software to meet this scope? – Is the project feasible?
- 39. Feasibility • Software feasibility has four dimensions – Technology – Is the project technically feasible? Is it within the state of the art? Can defects be reduced to a level matching the application's needs? – Finance – Is financially feasible? Can development be completed at a cost that the software organization, its client, or the market can afford? – Time – Will the project's time-to- market beat the competition? – Resources – Does the software organization have the resources needed to succeed in doing the project?
- 41. Estimation • “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.” Futrell, Shafer and Shafer, “Quality Software Project Management”
- 42. Why its important to you! • Program development of large software systems normally experience 200-300% cost overruns and a 100% schedule slip • 15% of large projects deliver…NOTHING! • Key reasons…poor management and inaccurate estimations of development cost and schedule • If not meeting schedules, developers often pay the price!
- 43. The Problems • Predicting software cost • Predicting software schedule • Controlling software risk • Managing/tracking project as it progresses
- 44. Resource Estimation • Three major categories of software engineering resources – People – Development environment – Reusable software components • Often neglected during planning but become a paramount concern during the construction phase of the software process • Each resource is specified with – A description of the resource – A statement of availability – The time when the resource will be required – The duration of time that the resource will be applied Time window
- 45. Categories of Resources People - Number required - Skills required - Geographical location Development Environment - Software tools - Computer hardware - Network resources Reusable Software Components - Off-the-shelf components - Full-experience components - Partial-experience components - New components The Project
- 46. Estimation of Project Cost and Effort
- 49. Factors Affecting Project Estimation • The accuracy of a software project estimate is predicated on – The degree to which the planner has properly estimated the of the product to be built – The ability to translate the size estimate into human effort, calendar time, and money – The degree to which the project plan reflects the abilities of the software team – The stability of both the product requirements and the environment that supports the software engineering effort
- 50. Project Estimation Options • Options for achieving reliable cost and effort estimates 1) Delay estimation until late in the project (we should be able to achieve 100% accurate estimates after the project is complete) 2) Base estimates on similar projects that have already been completed 3) Use relatively simple decomposition techniques to generate project cost and effort estimates 4) Use one or more empirical estimation models for software cost and effort estimation • Option #1 is not practical, but results in good numbers • Option #2 can work reasonably well, but it also relies on other project influences being roughly equivalent • Options #3 and #4 can be done in tandem to cross check each other
- 51. Project Estimation Approaches • Decomposition techniques – These take a "divide and conquer" approach – Cost and effort estimation are performed in a stepwise fashion by breaking down a project into major functions and related software engineering activities • Empirical estimation models – Offer a potentially valuable estimation approach if the historical data used to seed the estimate is good
- 52. Decomposition Techniques • Before an estimate can be made and decomposition techniques applied, the planner must – Understand the scope of the software to be built – Generate an estimate of the software’s size • Then one of two approaches are used – Problem-based estimation • Based on either source lines of code or function point estimates – Process-based estimation • Based on the effort required to accomplish each task
- 53. Approaches to Software Sizing • Function point sizing – Develop estimates of the information domain characteristics (Ch. 15 – Product Metrics for Software) • Standard component sizing – Estimate the number of occurrences of each standard component – Use historical project data to determine the delivered LOC size per standard component • Change sizing – Used when changes are being made to existing software – Estimate the number and type of modifications that must be accomplished – Types of modifications include reuse, adding code, changing code, and deleting code – An effort ratio is then used to estimate each type of change and the size of the change
- 54. Problem-Based Estimation 1) Start with a bounded statement of scope 2) Decompose the software into problem functions that can each be estimated individually 3) Compute an LOC or FP value for each function 4) Derive cost or effort estimates by applying the LOC or FP values to your baseline productivity metrics (e.g., LOC/person-month or FP/person-month) 5) Combine function estimates to produce an overall estimate for the entire project
- 55. Process-Based Estimation 1) Identify the set of functions that the software needs to perform as obtained from the project scope 2) Identify the series of framework activities that need to be performed for each function 3) Estimate the effort (in person months) that will be required to accomplish each software process activity for each function 4) Apply average labor rates (i.e., cost/unit effort) to the effort estimated for each process activity 5) Compute the total cost and effort for each function and each framework activity 6) Compare the resulting values to those obtained by way of the LOC and FP estimates • If both sets of estimates agree, then your numbers are highly reliable • Otherwise, conduct further investigation and analysis concerning the function and activity breakdown
- 56. Reconciling Estimates • The results gathered from the various estimation techniques must be reconciled to produce a single estimate of effort, project duration, and cost • If widely divergent estimates occur, investigate the following causes – The scope of the project is not adequately understood or has been misinterpreted by the planner – Productivity data used for problem-based estimation techniques is inappropriate for the application, obsolete (i.e., outdated for the current organization), or has been misapplied • The planner must determine the cause of divergence and then reconcile the estimates
- 57. Empirical Estimation Models • Estimation models for computer software use empirically derived formulas to predict effort as a function of LOC or FP • Resultant values computed for LOC or FP are entered into an estimation model • The empirical data for these models are derived from a limited sample of projects – Consequently, the models should be calibrated to reflect local software development conditions
- 58. COCOMO • Stands for COnstructive COst MOdel • Introduced by Barry Boehm in 1981 in his book “Software Engineering Economics” • Became one of the well-known and widely-used estimation models in the industry • It has evolved into a more comprehensive estimation model called COCOMO II • COCOMO II is actually a hierarchy of three estimation models • As with all estimation models, it requires sizing information and accepts it in three forms: object points, function points, and lines of source code
- 59. COCOMO Models • Application composition model - Used during the early stages of software engineering when the following are important – Prototyping of user interfaces – Consideration of software and system interaction – Assessment of performance – Evaluation of technology maturity • Early design stage model – Used once requirements have been stabilized and basic software architecture has been established • Post-architecture stage model – Used during the construction of the software
- 60. An Example: COCOMO Model • We consider the COCOMO (Constructive Cost Model) . • Decompose the software into small enough units to be able to estimate the LOC. • Definitions: – KDSI as kilo delivered source instructions (statements) • not including comments, test drivers, etc. – PM - person months • 3 levels of the Cocomo models: Basic, Intermediate and, Detailed (We will not see the last one here) Apply the following formulae to get rough estimates: – PM = 2.4(KDSI)1.05 – TDEV = 2.5(PM)0.38 (chronological months)
- 62. Software Project Management Project: Planned set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations.
- 63. The Management Spectrum • Effective software project management focuses on these items (in this order) – The people • Deals with the cultivation of motivated, highly skilled people • Consists of the stakeholders, the team leaders, and the software team – The product • Product objectives and scope should be established before a project can be planned – The process • The software process provides the framework from which a comprehensive plan for software development can be established – The project • Planning and controlling a software project is done for one primary reason… it is the only known way to manage complexity
- 65. The People: The Stakeholders • Five categories of stakeholders – Senior managers – define business issues that often have significant influence on the project – Project (technical) managers – plan, motivate, organize, and control the practitioners who do the work – Practitioners – deliver the technical skills that are necessary to engineer a product or application – Customers – specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome – End users – interact with the software once it is released for production use
- 67. The Product • The scope of the software development must be established and bounded – Context – How does the software to be built fit into a larger system, product, or business context, and what constraints are imposed as a result of the context? – Information objectives – What customer-visible data objects are produced as output from the software? What data objects are required for input? – Function and performance – What functions does the software perform to transform input data into output? Are there any special performance characteristics to be addressed? • Software project scope must be unambiguous and understandable at both the managerial and technical levels
- 69. The Process • Getting Started – The project manager must decide which process model is most appropriate based on • The customers who have requested the product and the people who will do the work • The characteristics of the product itself • The project environment in which the software team works – Once a process model is selected, a preliminary project plan is established based on the process framework activities – Process decomposition then begins – The result is a complete plan reflecting the work tasks required to populate the framework activities • Project planning begins as a melding of the product and the process based on the various framework activities
- 71. The Project: A Common Sense Approach • Start on the right foot – Understand the problem; set realistic objectives and expectations; form a good team • Maintain momentum – Provide incentives to reduce turnover of people; emphasize quality in every task; have senior management stay out of the team’s way • Track progress – Track the completion of work products; collect software process and project measures; assess progress against expected averages • Make smart decisions – Keep it simple; use COTS or existing software before writing new code; follow standard approaches; identify and avoid risks; always allocate more time than you think you need to do complex or risky tasks • Conduct a post mortem analysis – Track lessons learned for each project; compare planned and actual schedules; collect and analyze software project metrics; get feedback from teams members and customers; record findings in written form
- 72. The Project: The W5 HH Principle • Why is the system being developed? – Assesses the validity of business reasons and justifications • What will be done? – Establishes the task set required for the project • When will it be done? – Establishes a project schedule • Who is responsible for a function? – Defines the role and responsibility of each team member • Where are they organizationally located? – Notes the organizational location of team members, customers, and other stakeholders • How will the job be done technically and managerially? – Establishes the management and technical strategy for the project • How much of each resource is needed? – Establishes estimates based on the answers to the previous questions A series of questions that lead to a definition of key project characteristics and the resultant project plan
- 74. End of Unit 1: Introduction to Software Engineering
- 75. FAQ on Unit 1 Type Examples What/Define Software, Software Engineering, legacy Software, software process, project planning, estimation, management….. list Software Myths, legacy s/w characteristics, generic process framework activities, umbrella activities, project management activities, ways to do estimation, models for estimation emperically… Reason/ Why Use Software Engg, use process framework, use of legacy s/w, each s/w myth, why plan a project, why estimate cost, resources and people, why use empirical model… And in the similar way you can think of differences, advantages, limitations, examples ….. On these topics