Note for Software Engineering - SE by Ajmal Hasan

Topics ( 12 )

Text from page-1

Unit-1 –Introduction to Software and Software Engineering (1) Software & Software Engineering Software:   Computer software is the product that software professionals build and then support over the long term. It encompasses programs that execute within a computer of any size and architecture, content that is presented as the computer programs execute, and descriptive information in both hard copy and virtual forms that encompass virtually any electronic media. Characteristics of software : [1] Software is developed or engineered; it is not manufactured in the classical sense:   Although some similarities exist between software development and hardware manufacturing, but few activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems than software. [2] Software doesn’t “wear out.”        Hardware components suffer from the growing effects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out. Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the “idealized curve”. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. Therefore, the software maintenance tasks that accommodate requests for change involve considerably more complexity than hardware maintenance. However, the implication is clear—software doesn’t wear out. But it does deteriorate. Hardware Failure curve Software Failure curve [3] Although the industry is moving toward component-based construction, most software continues to be custom built.  A software component should be designed and implemented so that it can be reused in many different programs. Prof. Rupesh G. Vaishnav, CE Department | 2160701 – Software Engineering 1

Text from page-2

Unit-1 –Introduction to Software and Software Engineering   Modern reusable components encapsulate both data and the processing that is applied to the data, enabling the software engineer to create new applications from reusable parts. In the hardware world, component reuse is a natural part of the engineering process Difference between program and software Program 1) Small in size. Software 1) Large in size. 2) Authors himself is user-soul. 2) Large number. 3) Single developer. 3) Team developer. 4) Adopt development. 4) Systematic development. 5) Lack proper interface. 5) Well define interface. 6) Large proper documentation. 6) Well documented Software Myths: Software myths are beliefs about software and the process used to build it. (1) Management Myths: Myth 1: 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:  The book of standards may very well exist, but is it used?  Are software practitioners aware of its existence?  Does it reflect modern software engineering practice? Is it complete? Is it adaptable?  Is it streamlined to improve time-to-delivery while still maintaining a focus on quality?  In many cases, the answer to all of these questions is no. Myth 2: If we get behind schedule, we can add more programmers and catch up. Reality:   Software development is not a mechanistic process like manufacturing. As new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort.  People can be added but only in a planned and well-coordinated manner. Myth 3: 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 outsources software projects. Prof. Rupesh G. Vaishnav, CE Department | 2160701 – Software Engineering 2

Text from page-3

Unit-1 –Introduction to Software and Software Engineering (2) Customer Myths: Myth 1: A general statement of objectives is sufficient to begin writing programs—we can fill in the details later. Reality:  Although a comprehensive and stable statement of requirements is not always possible, an ambiguous “statement of objectives” is a recipe for disaster.  Unambiguous requirements are developed only through effective and continuous communication between customer and developer. Myth 2: Software requirements continually change, but change can be easily accommodated because software is flexible. Reality:    It is true that software requirements change, but the impact of change varies with the time at which it is introduced. When requirements changes are requested early the cost impact is relatively small. However, as time passes, the cost impact grows rapidly—resources have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification. (3) Practitioner’s Myths: Myth 1: Once we write the program and get it to work, our job is done. Reality:  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. Myth 2: 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 technical review. Software reviews are a “quality filter” that have been found to be more effective than testing for finding certain classes of software defects. Myth 3: 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. A variety of work products (e.g., models, documents, plans) provide a foundation for successful engineering and, more important, guidance for software support. Prof. Rupesh G. Vaishnav, CE Department | 2160701 – Software Engineering 3

Text from page-4

Unit-1 –Introduction to Software and Software Engineering Myth 4: 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 a quality product. Better quality leads to reduced rework. And reduced rework results in faster delivery times. Software Engineering:  Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. A Layered Technology: Figure: Software Engineering Layers 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 foundation that supports software engineering is a quality focus. Process:    The software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework that must be established for effective delivery of software engineering technology. The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products are produced, milestones are established, quality is ensured, and change is properly managed. Methods:    Software engineering methods provide the technical aspects for building software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. Software engineering methods rely on the set of modeling activities and other descriptive techniques. Prof. Rupesh G. Vaishnav, CE Department | 2160701 – Software Engineering 4