lecture1.ppt of software engineering of CSE
- 1. Introduction to Software Engineering UNIT - I Generic view of process
- 2. Nature of Software Software is a product • Transforms information - produces, manages, acquires, modifies, displays, or transmits information • Delivers computing potential of hardware and networks Software is a vehicle for delivering a product • Control the computer(operating system) • Communication of information (networking software) • Creation and control of other programs(software tools & environments) Silpa C
- 3. What is Software ? Software can be considered as: • Instruction – executed to provide desire features, function & performance. • Data structure – to adequately manipulate operation. • Documents – operation and use of the program. Software products may be developed for a particular customer or may be developed for a general market. Software products may be • Generic - developed to be sold to a range of different customers e.g. PC software such as Excel or Word. • Specific (custom) - developed for a single customer according to their specification. Silpa C
- 4. Hardware versus Software Hardware Software • Manufactured • wear out • Built using components • Relatively simple • Developed/ engineered • deteriorate • Custom built • Complex Silpa C
- 5. Manufacturing vs. Development • Once a hardware product has been manufactured, it is difficult or impossible to modify. In contrast, software products are routinely modified and upgraded. • In hardware, hiring more people allows you to accomplish more work, but the same does not necessarily hold true in software engineering. • Unlike hardware, software costs are concentrated in design rather than production. Silpa C
- 6. Failure curve for Hardware Silpa C
- 7. Failure curve for Software Silpa C
- 8. Failure curve for Hardware Failure curve for Software Silpa C
- 9. Software Application Domains • System software • Application software • Engineering/scientific software • Embedded software • Product line software • Web applications • Artificial intelligence software Silpa C
- 10. System Software: • System software is a collection of programs written to service other programs. • It is characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing, and sophisticated process management; complex data structures; and multiple external interfaces. Ex. Compilers, operating system, drivers etc. Application Software : • Application software consists of standalone programs that solve a specific business need. • Application software is used to control the business function in real-time. Ex. Point of sale transaction processing, real time manufacturing process control Engineering /Scientific software: • Characterized by "number crunching" algorithms. • Applications range from astronomy to volcano logy, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing. Ex. Computer Aided Design (CAD), system stimulation etc. Silpa C
- 11. Embedded Software: • It resides in read-only memory and is used to control products and systems • Embedded software can perform limited and esoteric functions. Ex. keypad control for a microwave oven. Product line software: • Designed to provide a specific capability for use by many different customers, product line software can focus on a limited and esoteric marketplace. Ex. Word processing, spreadsheet, CG, multimedia, etc. Web Applications: • Web apps can be little more than a set of linked hypertext files. • It evolving into sophisticated computing environments that not only provide standalone features, functions but also integrated with corporate database and business applications. Artificial Intelligence software • AI software makes use of non-numerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis Ex. Robotics, expert system, game playing, etc. Silpa C
- 12. Software Process • What? A software process – as a framework for the tasks that are required to build high-quality software. • Who? Managers, software engineers, and customers. • Why? Provides stability, control, and organization to an activity. • Steps? A handful of activities are common to all software processes, details vary. • Work product? Programs, documents, and data. Silpa C
- 13. What is software engineering? • Definition : The application of systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software • Software engineers should adopt – Systematic and organized approach to their work – Use appropriate tools and techniques depending on the problem to be solved – The development constraints and the resources available • Challenge for Software Engineers is to produce high quality software with finite amount of resources & within a predicted schedule Silpa C
- 14. Software Engineering – Layered Technology Layered Technology A quality focus: the “bedrock” A quality focus: the “bedrock” Process model: the “framework” Process model: the “framework” Methods: technical “how to’s” Methods: technical “how to’s” Tools: CASE preferred Tools: CASE preferred Silpa C
- 15. Layered Technology A quality Focus: • Every organization is rest on its commitment to quality. • Total quality management, Six Sigma, or similar continuous improvement culture and it is this culture ultimately leads to development of increasingly more effective approaches to software engineering. • The bedrock that supports software engineering is a quality focus. Process: • It’s a foundation layer for software engineering. • It’s define framework for a set of key process areas (KRA) for effectively manage and deliver quality software in a cost effective manner • The processes define the tasks to be performed and the order in which they are to be performed Silpa C
- 16. Methods: • It provide the technical how-to's for building software. • Methods encompass a broad array of tasks that include requirements analysis, design, program construction, testing, and support. • There could be more than one technique to perform a task and different techniques could be used in different situations. Tools: • Provide automated or semi-automated support for the process, methods and quality control. • When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering (CASE) Layered Technology Silpa C
- 17. Process Framework Process framework Process framework Umbrella Activities Umbrella Activities Framework activity 1 Framework activity 1 Framework activity n Framework activity n Software Process Software Process Framework activities Framework activities work tasks work tasks work products work products milestones & deliverables milestones & deliverables QA checkpoints QA checkpoints Process Framework Process Framework Umbrella Activities Umbrella Activities Silpa C
- 18. Process framework • A process is a collection of activities(communication with stakeholder), actions(agricultural design), and tasks(an architectural model) that are performed when some work product is to be created. • A process defines who is doing what, when and how to reach a certain goal. To build complete software process: • Identify a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. • It encompasses a set of umbrella activities that are applicable across the entire software process. Silpa C
- 19. Generic Process Framework Activities • Communication: – Heavy communication with customers, stakeholders, team – Encompasses requirements gathering and related activities • Planning: – Workflow that is to follow – Describe technical task, likely risk, resources will require, work products to be produced and a work schedule. • Modeling: – Help developer and customer to understand requirements (Analysis of requirements) & Design of software • Construction – Code generation: either manual or automated or both – Testing – to uncover error in the code. • Deployment: – Delivery to the customer for evaluation – Customer provide feedback Silpa C
- 20. The Process Model: Adaptability • The framework activities will always be applied on every project ... BUT The tasks for each activity will vary based on: – The type of project (an “entry point” to the model) – Characteristics of the project – Common sense judgment; concurrence of the project team Silpa C
- 21. • Umbrella activities are applied throughout the software project and help a software team manage and control progress, quality, change and risk. • Software project tracking and control – Assessing progress against the project plan. – Take adequate action to maintain schedule. • Formal technical reviews – Assessing software work products in an effort to uncover and remove errors before goes into next action or activity. • Software quality assurance – Define and conducts the activities required to ensure software quality. Umbrella Activities Silpa C
- 22. Cont… • Software configuration management – Manages the effects of change. • Reusability management – Define criteria for work product reuse – Mechanisms to achieve reusable components. • Measurement – Define and collects process, project, and product measures – Assist the team in delivering software that meets customer’s needs. • Risk management – Assesses risks that may effect that outcome of project or quality of product (i.e. software) Silpa C
- 23. Software Engineering Practice Here you can gain a basic understanding of the generic concepts and principles that apply to framework activities. Essence of practice 1. Understand the problem(communication and analysis) 2. Plan a solution(modeling and software design) 3. Carry out plan(code generation) 4. Examine the result for accuracy(testing and quality assurance) These steps lead to series of essential questions: Silpa C
- 24. Understand the problem • Who are stakeholders • Who are unknowns • Can the problem be compartmentalized • Can the problem be represented graphically Plan a solution • Have you seen similar problems before • Has a similar problem been solved • Can subproblems be defined • Can you represent a solution in a manner that leads to effective implementation Silpa C
- 25. Carry out plan • Does the solution confirm to the plan • Is each component part of the solution provably correct Examine the result • Is it possible to test each component part of the solution • Does the solution produce results that conform to the data, functions, and features that are required Silpa C
- 26. General Principles 1. The Reason It All Exists 2. Keep It Simple (KIS) 3. Maintain the Vision 4. What You Produce, Others Will Consume 5. Be Open to the Future 6. Plan Ahead for Reuse 7. Think! Silpa C
- 27. Software Development Myths Definition: Beliefs about software and the process used to build it. Myths have number of attributes that have made them insidious (i.e. dangerous). Misleading Attitudes - caused serious problem for managers and technical people. Management myths Managers in most disciplines, are often under pressure to maintain budgets, keep schedules on time, and improve quality. Myth: We already have a book that's full of standards and procedures for building software, won't that provide my people with everything they need to know? Reality : • Are software practitioners aware of existence standards? • Does it reflect modern software engineering practice? • Is it complete? Is it streamlined to improve time to delivery while still maintaining a focus on quality? Silpa C
- 28. Myth: If we get behind schedule, we can add more programmers and catch up Reality: Software development is not a mechanistic process like manufacturing. Adding people to a late software project makes it later. People can be added but only in a planned and well-coordinated manner Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm build it. Reality: If an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsource software projects cont… Silpa C
- 29. Customer Myths Customer may be a person from inside or outside the company that has requested software under contract. Myth: A general statement of objectives is sufficient to begin writing programs— we can fill in the details later. Reality: A poor up-front definition is the major cause of failed software efforts. A formal and detailed description of the information domain, function, behavior, performance, interfaces, design constraints, and validation criteria is essential. These characteristics can be determined only after thorough communication between customer and developer. Myth: Project requirements continually change, but change can be easily accommodated because software is flexible. Reality: Customer can review requirements and recommend modifications with relatively little impact on cost. When changes are requested during software design, the cost impact grows rapidly. Below mentioned figure for reference. Silpa C
- 30. Silpa C
- 31. Practitioner's myths Myth1: Once we write the program and get it to work, our job is done. Reality: Someone once said that "the sooner you begin 'writing code', the longer it'll take you to get done." Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time. Myth2: Until I get the program "running" I have no way of assessing its quality. Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project—the formal technical review. Silpa C
- 32. Myth3: The only deliverable work product for a successful project is the working program. Reality: A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and, more important, guidance for software support. Myth4 : Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down. Reality: Software engineering is not about creating documents. It is about creating quality. Better quality leads to reduced rework. And reduced rework results in faster delivery times. cont… Silpa C