×
Don’t stop when you’re tired. STOP when you are DONE.
--Your friends at LectureNotes
Close

Software Engineering

by Tulasi Miriyala
Type: NoteInstitute: Andhra University Views: 43Uploaded: 4 months agoAdd to Favourite

Share it with your friends

Suggested Materials

Leave your Comments

Contributors

Tulasi Miriyala
Tulasi Miriyala
SE UNIT-1 SOFTWARE ENGINEERING: Software engineering is the process of solving customers’ problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints. STAKEHOLDERS IN SOFTWARE ENGINEERING: Many people are involved in a software engineering project and expect to benefit from its success. We will classify these stakeholders into four major categories. ■ Users: These are the people who will use the software. Their goals usually include doing enjoyable or interesting work, and gaining recognition for the work they have done. ■ Customers (also known as clients): These are the people who make the decisions about ordering and paying for the software. They may or may not be users – the users may work for them. Their goal is either to increase profits or simply to run their business more effectively. Customers appreciate software that helps their organization save or make money, typically by improving the productivity of the users and the organization as a whole. ■ Software developers: These are the people who develop and maintain the software, many of whom may be called software engineers. Within the development team there are often specialized roles, including requirements specialists, database specialists, technical writers, configuration management specialists, etc. ■ Development managers. These are the people who run the organization that is developing the software; they often have an educational background in business administration. Their goal is to please the customer or sell the most software, while spending the least money. TYPES OF SOFTWARE AND THEIR DIFFERENCES: There are many different types of software. One of the most important distinctions is between custom software, generic software and embedded software. Custom software: Custom software is developed to meet the specific needs of a particular customer and tends to be of little use to others. Much custom software is developed in-house within the same organization that uses it; in other cases, the development is contracted out to consulting companies. Custom software is typically used by only a few people and its success depends on meeting their needs. Examples: include web sites, air-traffic control systems and software for managing the specialized finances of large organizations. Generic software: Generic software, on the other hand, is designed to be sold on the open market, to perform functions that many people need, and to run on general purpose computers. Requirements are determined largely by market research. There is a tendency in the business world to attempt to use generic software instead of custom software because it can be far cheaper and more reliable. The main difficulty is that it might not fully meet the organization’s specific needs. Generic software is often called Commercial Off-The-Shelf software (COTS), and it is sometimes also called shrink-wrapped software since it is commonly sold in packages wrapped in plastic. Generic software producers hope that they will sell many copies, but their success is at the mercy of market forces. Examples: include word processors, spreadsheets, compilers, web browsers, operating systems, computer games and accounting packages for small businesses. Embedded software: Embedded software runs specific hardware devices which are typically sold on the open market. Such devices include washing machines, DVD players, microwave ovens and automobiles. Since embedded systems are finding their way into a vast number of consumer and commercial products, they now account for the bulk of software copies in existence.
SOFTWARE ENGINEERING PROJECTS: Software engineering work is normally organized into projects. For a small software system, there may only be a single team of three or four developers working on the project. For a larger system, the work is usually subdivided into many smaller projects. We can divide software projects into three major categories: 1) Those that involve modifying an existing system 2) Those that involve starting to develop a system from scratch 3) Those that involve building most of a new system from existing components, while developing new software only for missing details. 1. Evolutionary projects: Most software projects are of the first type – modifying an existing system. The term maintenance is often used to describe this process; however, for many people the word maintenance implies keeping something running by simply fixing problems, but without adding significant new features. We will thus use the term evolution to more accurately describe what happens to software over its life-span. Evolutionary or maintenance projects can be of several different types: ■ Corrective projects involve fixing defects. ■ Adaptive projects involve changing the system in response to changes in the environment in which the software runs. For example, it might be necessary to make changes so that the system will continue to work with a new version of the operating system or database, or with a new set of tax laws. ■ Enhancement projects involve adding new features for the users. ■ Re-engineering or perfective projects involve changing the system internally so that it is more maintainable, without making significant changes that the user will notice. This occurs when customers constantly want new features added, so the software becomes so large and bloated that it becomes difficult to maintain at a high level of quality. 2. Greenfield projects: Projects to develop an entirely new software system from scratch are significantly less common than evolutionary projects. Developers often enjoy such brand new, or greenfield, projects because they have a wider freedom to be creative about the design. In a greenfield project you are not constrained by the design decisions and errors made by predecessors. However, it takes a lot of work to build a complex system from scratch. 3. Projects that involve building on a framework or a set of existing components: The third type of software project can be considered neither evolutionary nor new development. This type of project, which is becoming increasingly common, starts with a framework, or involves plugging together several components that are already developed and provide significant functionality. A framework is a software system especially designed to be reused in different projects, or in the various products of a product line. A framework contains important functionality, but must be adapted to handle the requirements of particular customers or products. For example, imagine an application framework for ticketing. Such a system would have basic capabilities for reserving and printing tickets for events or travel. ACTIVITIES COMMON TO SOFTWARE PROJECTS: Many of the activities commonly found in software engineering projects. 1. Requirements and specification: In order to solve the customer’s problems, you must first understand the problems, the customer’s business environment, and the available technology which can be used to solve the problems. This overall process may include the following activities. A. Domain analysis: understanding the background needed so as to be able to understand the problem and make intelligent decisions. B. Defining the problem: narrowing down the scope of the system by determining the precise problem that needs solving. C. Requirements gathering: obtaining all the ideas people have about what the software should do.
D. Requirements analysis: organizing the information that has been gathered, and making decisions about what in fact the software should do. The term ‘requirements analysis’ is often used more broadly to include some of the other steps in this list. E. Requirements specification: writing a precise set of instructions that define what the software should do. These instructions should describe how the software behaves from the perspective of the user, but should not describe any details of the implementation. One of the most important principles of requirements is to separate the ‘what’ from the ‘how’. The ‘what’ refers to the requirements – what is needed to solve the problem. The ‘how’ refers to how the solution will be designed and implemented. 2. Design: Design is the process of deciding how the requirements should be implemented using the available technology. Important activities during design include: ■ Deciding what requirements should be implemented in hardware and what in software. This is called systems engineering ■ Deciding how the software is to be divided into subsystems and how the subsystems are to interact. This process is often called software architecture, there are several well-known ways of structuring software which are called architectural patterns or styles. ■ Deciding how to construct the details of each subsystem. This process is often called detailed design. ■ Deciding in detail how the user is to interact with the system, and the look and feel of the system. This is called user interface design. ■ Deciding how the data will be stored on disk in databases or files. 3. Modeling: Modeling is the process of creating a representation of the domain or the software. Various modeling approaches can be used during both requirements analysis and design. These include: ■ Use case modeling: This involves representing the sequences of actions performed by the users of the software. ■ Structural modeling: This involves representing such things as the classes and objects present in the domain or in the software. ■ Dynamic and behavioral modeling: This involves representing such things as the states that the system can be in, the activities it can perform, and how its components interact. Modeling can be performed visually, using diagrams, or else using semi-formal or formal languages that express the information systematically or mathematically. In this book, we will primarily use semi-formal notations and diagrams – in particular a visual language called UML. 4. Programming: Programming is an integral part of software engineering. It involves the translation of higherlevel designs into particular programming languages. It should be thought of as the final stage of design because it involves making decisions about the appropriate use of programming language constructs, variable declarations etc. Most people who call themselves programmers also perform many higher-level design activities. People who limit their work to programming are often today called ‘coders’. 5. Quality assurance: Quality assurance (QA) encompasses all the processes needed to ensure that the quality objectives discussed in Section 1.5 are met. Quality assurance occurs throughout a project, and includes many activities, including the following: ■ Reviews and inspections. These are formal meetings organized to discuss requirements, designs or code to see if they are satisfactory. ■ Testing. This is the process of systematically executing the software to see if it behaves as expected. Quality assurance is also often divided into validation, which is the process of determining whether the requirements will solve the customer’s problem, and verification, which is the process of making sure the requirements have been adhered to.
6. Deployment: Deployment involves distributing and installing the software and any other components of the system such as databases, special hardware etc. It also involves managing the transition from any previous system. 7. Managing software configurations: Configuration management involves identifying all the components that compose a software system, including files containing requirements, designs and source code. It also involves keeping track of these as they change, and ensuring that changes are performed in an organized way. All software engineers must participate in the configuration management of the parts of the system for which they are responsible. 8. Managing the process: Managing software projects is considered an integral part of software engineering. All software engineers assist their managers to some extent, and most will, at some point in their careers, become managers themselves. The manager has to undertake the following tasks: ■ Estimating the cost of the system. This involves studying the requirements and determining how much effort they will take to design and implement. ■ Planning. This is the process of allocating work to particular developers, and setting a schedule with deadlines. Both cost estimates and plans need to be examined and revised on a regular basis, since initial estimates will only be rough. DATA ABSTRACTION: Data abstraction refers to providing only essential information to the outside world and hiding their background details, i.e., to represent the needed information in program without presenting the details. Data abstraction is a programming (and design) technique that relies on the separation of interface and implementation. In C++, classes provides great level of data abstraction. They provide sufficient public methods to the outside world to play with the functionality of the object and to manipulate object data, i.e., state without actually knowing how class has been implemented internally. INHERITANCE: One of the most important concepts in object-oriented programming is that of inheritance. Inheritance allows us to define a class in terms of another class, which makes it easier to create and maintain an application. This also provides an opportunity to reuse the code functionality and fast implementation time. When creating a class, instead of writing completely new data members and member functions, the programmer can designate that the new class should inherit the members of an existing class. This existing class is called the baseclass, and the new class is referred to as the derived class. The idea of inheritance implements the is a relationship. For example, mammal IS-A animal, dog IS-A mammal hence dog IS-A animal as well and so on. Base and Derived Classes A class can be derived from more than one classes, which means it can inherit data and functions from multiple base classes. To define a derived class, we use a class derivation list to specify the base class(es). A class derivation list names one or more base classes and has the form − class derived-class: access-specifier base-class Where access-specifier is one of public, protected, or private, and base-class is the name of a previously defined class. If the access-specifier is not used, then it is private by default. Type of Inheritance When deriving a class from a base class, the base class may be inherited through public, protected or private inheritance. The type of inheritance is specified by the access-specifier as explained above. We hardly use protected or private inheritance, but public inheritance is commonly used. While using different type of inheritance, following rules are applied −

Lecture Notes