Page 1 :
Software Engineering Fundamentals, Definition of software:Software is a program that enables a computer to perform a specific task. Computer, software has to be "loaded" into the computer's storage (such as a hard drive, memory, or, RAM). Once the software is loaded, the computer is able to execute the software., Examples of applications include office suites, database programs, web browsers, word, processors, software development tools, image editors and communication platforms. System, software includes operating systems and any program that supports application software., The importance of software:-Software plays an important role in managing business operations, as per needs. With the help of software, we can manage and maintain business easily and, eliminate human errors. Also, It is helpful in increasing productivity, efficiency and effectiveness, of the organization activities., 1.The economies of all developed nations are depend on software., 2.More and more systems are software controlled., 3.software costs more to maintain than to develop., 4.The costs of software on PC is often greater than hardware cost., Software myths:Beliefs about software and the process used to build it., The software myths can affect:1.Managers., 2.Customers., Myth:-If we get behind schedule,add more programmers., Reality:-Adding people to a late software project makes it later., Myth:-Software engineering will make us create many and unnecessary documentation., Reality:-Software engineering is not about to creating documents. It is about to creating quality., Better quality leads to reduced rework. Reduced rework results in faster delivery time.
Page 2 :
The Software Crisis, •, , •, , The most visible symptoms of the software crisis are, o Late delivery, over budget, o Product does not meet specified requirements, o Inadequate documentation, Some observations on the software crisis, o Software system requirements are moving targets, o There may not be enough good developers around to create all the new software, that users need, o A significant portion of developer time must often be dedicated to the maintenance, or preservation of geriatric software., , Software Engineering:•, , Software engineering may be defined as, o the study of software process, development principles, techniques and notations, o the production of quality software, that is delivered on time, within budget, and, adequately meets its users needs and expectations, o the disciplined application of engineering, scientific and mathematical principles, and methods in the economical production of quality software
Page 3 :
Software is more than just a program code. A program is an executable code, which serves, some computational purpose. Software is considered to be collection of executable, programming code, associated libraries and documentations. Software, when made for a, specific requirement is called software product., Engineering on the other hand, is all about developing products, using well-defined, scientific, principles and methods., Software engineering is an engineering branch associated with development of software, product using well-defined scientific principles, methods and procedures. The outcome of, software engineering is an efficient and reliable software product.
Page 4 :
Definitions :, IEEE defines software engineering as, • The application of a systematic, disciplined, quantifiable approach to the, development, operation, and maintenance of software; that is, the, application of engineering to software., • Fritz Bauer, a German computer scientist, defines software engineering as:, “Software engineering is the establishment and use of sound engineering, principles in order to obtain economically software that is reliable and, work efficiently on real machines.”, Software Paradigms :, Software paradigms refer to the methods and steps, which are taken while, designing the software. There are many methods proposed and are implemented., But, we need to see where in the software engineering concept, these paradigms, stand. These can be combined into various categories, though each of them is, contained in one another:, Programming paradigm is a subset of Software design paradigm which is further, a subset of Software development paradigm., Software Development Paradigm, This paradigm is known as software engineering paradigms; where all the, engineering concepts pertaining to the development of software are applied. It, includes various researches and requirement gathering which helps the software, product to build. It consists of, • Requirement gathering, • Software design, • Programming, Software Design Paradigm, This paradigm is a part of Software Development and includes –, • Design, • Maintenance, • Programming
Page 5 :
Programming Paradigm, This paradigm is related closely to programming aspect of software development., This includes –, • Coding, • Testing, • Integration, Need of Software Engineering, The need of software engineering arises because of higher rate of change, in user requirements and environment on which the software is working., Following are some of the needs stated:, • Large software - It is easier to build a wall than a house or building,, likewise, as the size of the software becomes large, engineering has to step, to give it a scientific process., •, , Scalability- If the software process were not based on scientific and, engineering concepts, it would be easier to re-create new software than to, scale an existing one., , •, , Cost- As hardware industry has shown its skills and huge manufacturing, has lower down the price of computer and electronic hardware. But, cost, of the software remains high if proper process is not adapted., , •, , Dynamic Nature- Always growing and adapting nature of the software, hugely depends upon the environment in which the user works. If the, nature of software is always changing, new enhancements need to be, done in the existing one. This is where the software engineering plays a, good role., , •, , Quality Management- Better process of software development provides, better and quality software product., , Characteristics of good software:, A software product can be judged by what it offers and how well it can be used., This software must satisfy on the following grounds:, • Operational, •, , Transitional, , • Maintenance
Page 6 :
Well-engineered and crafted software is expected to have the following, characteristics:, Operational, This tells us how well the software works in operations. It can be measured, on:, • Budget, •, , Usability, , •, , Efficiency, , •, , Correctness, , •, , Functionality, , •, , Dependability, , •, , Security, , •, , Safety, Transitional, This aspect is important when the software is moved from one platform to, another:, • Portability, •, , Interoperability, , •, , Reusability, , •, , Adaptability, Maintenance, This aspect briefs about how well the software has the capabilities to, maintain itself in the ever-changing environment:, • Modularity, •, , Maintainability, , • Flexibility, • Scalability, In short, Software engineering is a branch of computer science, which uses welldefined engineering concepts required to produce efficient, durable, scalable, inbudget, and on-time software products.
Page 7 :
Software process models:, 1)Linear sequential model:The Waterfall Model was the first Process Model to be introduced. It is also, referred to as a linear-sequential life cycle model. It is very simple to understand, and use. In a waterfall model, each phase must be completed before the next, phase can begin and there is no overlapping in the phases.The Waterfall model is, the earliest SDLC approach that was used for software development.The, waterfall Model illustrates the software development process in a linear, sequential flow. This means that any phase in the development process begins, only if the previous phase is complete. In this waterfall model, the phases do not, overlap., Waterfall Model - Design:Waterfall approach was first SDLC Model to be used widely in Software, Engineering to ensure success of the project. In "The Waterfall" approach, the, whole process of software development is divided into separate phases. In this, Waterfall model, typically, the outcome of one phase acts as the input for the, next phase sequentially., The following illustration is a representation of the different phases of the, Waterfall Model.
Page 8 :
The sequential phases in Waterfall model are −, •, , •, , •, , •, , •, , •, , Requirement Gathering and analysis − All possible requirements of the, system to be developed are captured in this phase and documented in a, requirement specification document., System Design − The requirement specifications from first phase are, studied in this phase and the system design is prepared. This system design, helps in specifying hardware and system requirements and helps in defining, the overall system architecture., Implementation − With inputs from the system design, the system is first, developed in small programs called units, which are integrated in the next, phase. Each unit is developed and tested for its functionality, which is, referred to as Unit Testing., Integration and Testing − All the units developed in the implementation, phase are integrated into a system after testing of each unit. Post, integration the entire system is tested for any faults and failures., Deployment of system − Once the functional and non-functional testing is, done; the product is deployed in the customer environment or released, into the market., Maintenance − There are some issues which come up in the client, environment. To fix those issues, patches are released. Also to enhance the, product some better versions are released. Maintenance is done to deliver, these changes in the customer environment., All these phases are cascaded to each other in which progress is seen, as flowing steadily downwards (like a waterfall) through the phases. The, next phase is started only after the defined set of goals are achieved for, previous phase and it is signed off, so the name "Waterfall Model". In this, model, phases do not overlap., , Waterfall Model - Application, Every software developed is different and requires a suitable SDLC, approach to be followed based on the internal and external factors. Some, situations where the use of Waterfall model is most appropriate are −, •, •, •, •, , Requirements are very well documented, clear and fixed., Product definition is stable., Technology is understood and is not dynamic., There are no ambiguous requirements.
Page 9 :
•, •, , Ample resources with required expertise are available to support the, product., The project is short., , Waterfall Model - Advantages, The advantages of waterfall development are that it allows for, departmentalization and control. A schedule can be set with deadlines for each, stage of development and a product can proceed through the development, process model phases one by one., Development moves from concept, through design, implementation, testing,, installation, troubleshooting, and ends up at operation and maintenance. Each, phase of development proceeds in strict order., Some of the major advantages of the Waterfall Model are as follows −, •, •, •, •, •, •, •, •, , Simple and easy to understand and use, Easy to manage due to the rigidity of the model. Each phase has specific, deliverables and a review process., Phases are processed and completed one at a time., Works well for smaller projects where requirements are very well, understood., Clearly defined stages., Well understood milestones., Easy to arrange tasks., Process and results are well documented., , Waterfall Model - Disadvantages, The disadvantage of waterfall development is that it does not allow much, reflection or revision. Once an application is in the testing stage, it is very difficult, to go back and change something that was not well-documented or thought upon, in the concept stage., The major disadvantages of the Waterfall Model are as follows −, •, •, •, •, , No working software is produced until late during the life cycle., High amounts of risk and uncertainty., Not a good model for complex and object-oriented projects., Poor model for long and ongoing projects.
Page 10 :
•, •, •, •, •, , Not suitable for the projects where requirements are at a moderate to high, risk of changing. So, risk and uncertainty is high with this process model., It is difficult to measure progress within stages., Cannot accommodate changing requirements., Adjusting scope during the life cycle can end a project., Integration is done as a "big-bang. at the very end, which doesn't allow, identifying any technological or business bottleneck or challenges early., Prototype Model:, , Prototyping is defined as the process of developing a working replication of, a product or system that has to be engineered. It offers a small scale facsimile of, the end product and is used for obtaining customer feedback as described below:
Page 11 :
The Prototyping Model is one of the most popularly used Software, Development Life Cycle Models (SDLC models).This model is used when the, customers do not know the exact project requirements beforehand. In this model,, a prototype of the end product is first developed, tested and refined as per, customer feedback repeatedly till a final acceptable prototype is achieved which, forms the basis for developing the final product., In this process model, the system is partially implemented before or during, the analysis phase thereby giving the customers an opportunity to see the, product early in the life cycle. The process starts by interviewing the customers, and developing the incomplete high-level paper model. This document is used to, build the initial prototype supporting only the basic functionality as desired by the, customer. Once the customer figures out the problems, the prototype is further, refined to eliminate them. The process continues till the user approves the, prototype and finds the working model to be satisfactory., There are 2 approaches for this model:, Rapid Throwaway Prototyping –, This technique offers a useful method of exploring ideas and getting customer, feedback for each of them. In this method, a developed prototype need not, necessarily be a part of the ultimately accepted prototype. Customer feedback, helps in preventing unnecessary design faults and hence, the final prototype, developed is of a better quality., 1. Evolutionary Prototyping –, In this method, the prototype developed initially is incrementally refined on, the basis of customer feedback till it finally gets accepted. In comparison to, Rapid Throwaway Prototyping, it offers a better approach which saves time, as well as effort. This is because developing a prototype from scratch for
Page 12 :
every iteration of the process can sometimes be very frustrating for the, developers.
Page 13 :
Advantages –, •, •, •, •, •, •, , The customers get to see the partial product early in the life cycle. This, ensures a greater level of customer satisfaction and comfort., New requirements can be easily accommodated as there is scope for, refinement., Missing functionalities can be easily figured out., Errors can be detected much earlier thereby saving a lot of effort and cost,, besides enhancing the quality of the software., The developed prototype can be reused by the developer for more, complicated projects in the future., Flexibility in design., , Disadvantages –, •, •, •, •, •, •, •, •, , Costly w.r.t time as well as money., There may be too much variation in requirements each time the prototype, is evaluated by the customer., Poor Documentation due to continuously changing customer requirements., It is very difficult for the developers to accommodate all the changes, demanded by the customer., There is uncertainty in determining the number of iterations that would be, required before the prototype is finally accepted by the customer., After seeing an early prototype, the customers sometimes demand the, actual product to be delivered soon., Developers in a hurry to build prototypes may end up with sub-optimal, solutions., The customer might lose interest in the product if he/she is not satisfied, with the initial prototype., , Use –, The Prototyping Model should be used when the requirements of the product are, not clearly understood or are unstable. It can also be used if requirements are, changing quickly. This model can be successfully used for developing user, interfaces, high technology software-intensive systems, and systems with, complex algorithms and interfaces. It is also a very good choice to demonstrate, the technical feasibility of the product.
Page 14 :
Rapid Application Development Model:Definition: The Rapid Application Development (or RAD) model is based on, prototyping and iterative model with no (or less) specific planning. In general,, RAD approach to software development means putting lesser emphasis on, planning tasks and more emphasis on development and coming up with a, prototype. In disparity to the waterfall model, which emphasizes meticulous, specification and planning, the RAD approach means building on continuously, evolving requirements, as more and more learnings are drawn as the, development progresses., Description: RAD puts clear focus on prototyping, which acts as an alternative to, design specifications. This means that RAD works well wherever there's a greater, focus on user interface rather than non-GUI programs. The RAD model includes, agile method and spiral model., Below phases are in rapid application development (RAD) model:, , 1. Business modeling: The information flow is identified between different, business functions., 2. Data modeling: Information collected from business modeling is used to define, data objects that are required for the business.
Page 15 :
3. Process modeling: Data objects defined in data modeling are converted to, establish the business information flow to achieve some specific business, objective process descriptions for adding, deleting, modifying data objects that, are given., 4. Application generation: The actual system is created and coding is done by, using automation tools. This converts the overall concept, process and related, information into actual desired output. This output is called a prototype as it’s still, half-baked., 5. Testing and turnover: The overall testing cycle time is reduced in the RAD, model as the prototypes are independently tested during every cycle., It focuses on input-output source and destination of the information. It, emphasizes on delivering projects in small pieces; the larger projects are divided, into a series of smaller projects. The main features of RAD model are that it, focuses on the reuse of templates, tools, processes, and code., However, the overall flow of information, user interfaces and other, program interfaces, and coaxials between these interfaces and the rest of data, flow need to be tested as per acceptance process. Since most of the programming, components have already been tested, it reduces the risk of any critical issue., Incremental Model:The incremental build model is a method of software development where the, product is designed, implemented and tested incrementally (a little more is, added each time) until the product is finished. It involves both development and, maintenance. The product is defined as finished when it satisfies all of its, requirements. This model combines the elements of the waterfall model with the, iterative philosophy of prototyping., The product is decomposed into a number of components, each of which is, designed and built separately (termed as builds). Each component is delivered to, the client when it is complete. This allows partial utilization of the product and, avoids a long development time. It also avoids a large initial capital outlay and, subsequent long waiting period. This model of development also helps ease the, traumatic effect of introducing a completely new system all at once.
Page 16 :
Characteristics of Incremental Model, 1., 2., 3., 4., , System is broken down into many mini development projects., Partial systems are built to produce the final system., First tackled highest priority requirements., The requirement of a portion is frozen once the incremented portion is, developed., , Advantages, 1. After each iteration, regression testing should be conducted. During this, testing, faulty elements of the software can be quickly identified because, few changes are made within any single iteration., 2. It is generally easier to test and debug than other methods of software, development because relatively smaller changes are made during each, iteration. This allows for more targeted and rigorous testing of each, element within the overall product., 3. Customer can respond to features and review the product for any needed, or useful changes., 4. Initial product delivery is faster and costs less., Disadvantage, 1. Resulting cost may exceed the cost of the organization., 2. As additional functionality is added to the product, problems may arise, related to system architecture which were not evident in earlier, prototypes.
Page 17 :
Spiral Model:The spiral model is a combination of sequential and prototype models. This, model is best used for large projects which involve continuous, enhancements. There are specific activities that are done in one iteration, (spiral) where the output is a small prototype of the large software. The, , same activities are then repeated for all the spirals until the entire software, is built., A spiral model has 4 phases described below:, 1., 2., 3., 4., , Planning phase, Risk analysis phase, Engineering phase, Evaluation phase.
Page 18 :
Activities which are performed in the spiral model phases are shown below:, Phase, Name, , Planning, , Risk, Analysis, , Activities performed, -Requirements are studied and, gathered., - Feasibility study, - Reviews and walkthroughs to, streamline the requirements, Requirements are studied and brain, storming sessions are done to identify, the potential risks, Once the risks are identified , risk, mitigation strategy is planned and, finalized, , Deliverables / Output, Requirements understanding, document, Finalized list of requirements., , Document which highlights, all the risks and its mitigation, plans., , Code, Actual development and testing if the Test cases and test results, Engineering, software takes place in this phase, Test summary report and, defect report., Customers evaluate the software and Features implemented, Evaluation, provide their feedback and approval document
Page 20 :
Component Assembly Model:-, , Before the concept of SDLC, different software programs were built to cater, to different business and consumer needs. That was decades ago and it’s safe to, say that millions of programs have been created for different reasons, for, different needs. Developers always work on a language to create programs with, different needs. Much of the man hours spent on creating a single program is, spent on coding. Developers have to deal with the language again and again until, a prototype is created., According to surveys, 72% of the developers always have to deal with over, spending. Project managers spend much on manpower to develop their software, or else the project will completely fail. Aside from paying different developers for, the man hours they spend on creating programs, project managers also have to, deal with the scarcity of talent. The scarcity of talent will always dictate a higher, than normal fee and today, that scarcity of talent is always there. Human, resource is always the biggest factor in why project managers have to spend more, than planned. This doesn’t even add in the required hardware necessary to create, a single program.
Page 21 :
Project managers have to create a development plan that will not require, manpower. Turn around time from planning to implementation should also be, shortened to cope with a fast changing web environment. This is the only way for, project managers to cut costs and be efficient at the same time., Answering that problem is a Software Development Life Cycle (SDLC) plan, called Component Assembly model. Instead of starting over with different codes, and languages, developers who use this model tap on the available components, and put them together to build a program. Component Assembly Model is an, iterative development model. It works like the Prototype model, constantly, creating a prototype until a software that will cater the need of businesses and, consumers is realized., Component Assembly model has a close resemblance with the Rapid, Application Development (RAD) model. This SDLC model uses the available tools, and GUIs to build software. With the number of SDKs released today, developers, will find it easier to build programs using lesser codes with the help of SDK. Since, it has enough time to concentrate on other parts of the programs aside from, coding language; RAD concentrates or user inputs and graphical interaction of the, user and program., Component Assembly Model on the other hand uses a lot of previously, made components. CAM doesn’t need to use SDKs to develop programs but it will, be putting together powerful components. All the developers has to do is to know, what the customer wants, look for the components to answer the need and put, together the components to create the program., Software Analysis Concepts and Principles, The overall role of software in large system is identified during system, engineering. However, it’s necessary to take a harder look at software’s role to, understand the specific requirements that must be achieved to build high-quality, software. That’s the job of software requirements analysis. To perform the job, properly you should follow a set of underlying concepts and principles., 1. Requirements Analysis, Requirement analysis is a software engineering task that bridges the gap between, system level requirements engineering and software design. Requirements, engineering activities result in the specification of software’s operational, characteristics, indicate software’s interface with other system elements, and
Page 22 :
establish constraints that software must meet. Requirement analysis allows the, software engineer to refine domains that will be treated by software., Software requirements analysis may be divided into five areas of effort:, (1) problem recognition,, (2) evaluation and synthesis,, (3) modeling,, (4) specification, and, (5) review., The analyst studies the system specification and the software Project Plan. It is, important to understand software in a system context and to review the software, scope that was used to generate planning estimates. Problem evaluation and, solution synthesis is the next major area of effort for analysis. The analyst must, define all externally observable data objects, evaluate the flow and content of, information, define and elaborate all software functions, understand software, behavior in the context of events that affect the system, establish system, interface characteristics, and uncover additional design constraints., Throughout evaluation and solution synthesis, the analyst’s primary focus is, on “what” not “how”. What data does the system produce and consume, what, functions must the system perform, what behavior does the system exhibit, what, interfaces are defined and what constraints apply?, 2. Requirements Elicitation for Software, Before requirements can be analyzed , modeled, or specified they must be, gathered through an elicitation process., 2.1 Initiating the Process, The first meeting between a software engineer and the customer can be liked to, the awkwardness of a first date between two adolescents. Communication must, be initiated by asking context-free questions. That is a set of questions that will, lead to basic understanding of the problem, the people who want a solution that, will lead to basic understanding of the problem, the people who want a solution,, the nature of the solution that is desired, and the effectiveness of the first, encounter itself., Who is behind the request for this work?, Who will use the solution?, What will be the economic benefit of a successful solution?, Is there another source for the solution that you need?
Page 23 :
The next set of questions enables the analyst to gain a better, understanding of the problem and the customer to voice his or her perceptions, about a solution:, • How would you characterize “good” output that would be generated by, a successful solution?, • What problem(s) will this solution address?, • Can you show me the environment in which the solution will be used?, • Will special performance issues or constrains affect the way the solution, is approached?, 2.2 Facilitated Application Specification Techniques, Customers and software engineers have an unconscious “us and them” mind-set., With these problems in the mind that a number of independent investigators, have developed a team-oriented approach to requirements gathering that is, applied during early stages of analysis and specification. Called facilitated, application technique (FAST). Basic guidelines for this technique are:, • A meeting is conducted at a neutral site and attended by both software, engineers and customers., • Rules for preparation and participation are established., • An agenda is suggested that is formal enough to cover all important, points but informal enough to encourage the free flow of ideas., • A “facilitator” controls the meeting., • A “definition mechanism” is used, The goal is to identify the problem, propose elements of the solution,, negotiate different approaches, and specify a preliminary set of solution, requirements in an atmosphere that is conductive to the accomplishment, of the goal., Initial meeting between the developer and customer occur and basic, questions and answers help to establish the scope of the problem and the over all, perception of a solution. The product request distributed to all attendees before, the meeting date. The FAST team is composed of representatives from marketing,, software and hardware engineering, and manufacturing. As the FAST meeting, begins, the first topic of discussion is the need and justification for the new, product – everyone should agree that the product justified. Once agreement has, been established, each participant his or her list for discussion.
Page 24 :
After individual lists are presented in one topic area, a combined list is, created by the group. The combined list eliminates redundant entries, adds any, new ideas that come up during the discussion, but does not delete anything. The, combined list is shortened, lengthened, or reworded to properly reflect the, product or system to be developed. The objective is to develop a consensus list in, each topic area. Each sub team presents its mini-specs to all FAST attendees for, discussion. After the mini-specs are completed, each FAST attendee makes a list, of validation criteria for the product or system and presents his or her to the, team., 2.3 Quality Function Deployment, Quality function deployment (QFD) is a quality management technique that, translates the needs of the customer into technical requirements for software., QFD identifies three types of requirements:, Normal requirements. The objectives and goals that are stated for a product or, system during meeting with customer. If these requirements are present, the, customer is satisfied., Expected requirements. These requirements are implicit to the product or system, and may be so fundamental that the customer does not explicitly state them., Their absence will be a cause for significant dissatisfaction., Exciting requirements. These features go beyond the customer’s expectations, and prove to be very satisfying when present., Functional deployment is used to determine the value of each function that, is required for the system. Information deployment identifies both the data, objects and events that the system must consume and produce. These are tied to, the functions. Finally, task deployment examines the behavior of the system or, product within the context of its environment. Value analysis is conducted to, determine the relative priority of requirements determined during each of the, three deployments., 2.4. Use-Cases, As requirements are gathered as part of informal meetings, a software engineer, can create a set of scenarios that identify a thread of usage for the system to be, constructed. To create a use-case, the analyst must first identify the different, types of people play as the system operates. Defined somewhat more formally an, actor is anything that communicates with the system or product and that is, external to the system itself., It’s most important to note that an actor and a user are not the same thing., An actor represents a class of external entities that play just one role. Once actors, have been identified, use-case can be developed. The use-case describes the, manner in which an actor interacts with the system. The use-case should be, answer below questions:
Page 25 :
• What main tasks or functions are performed by an actor?, • What system information will the actor acquire, produce, or change?, • Will the actor have to inform the system about changes in the external, environment?, • What information does the actor desire from the system?, • Does the actor wish to be informed about unexpected changes?, In general, use-case is simply a written narrative that describes the role of an, actor as interaction with the system occurs., 3. Analysis Principles, Over the past two decades, a large number of analysis modeling methods, have been developed. Investigators have identified analysis problems and their, causes and have developed a variety of notations and corresponding sets of, heuristics to overcome them. Each analysis method has a unique point of view., • The information domain of a problem must be represented and, understood., • The functions that the software is to perform must be defined., • The behavior of the software must be represented., • The models that depict information, function, and, • The models that depict information function and behavior must be, partitioned in a manner that uncovers details in a layered fashion., • The analysis process should move from essential information toward, implementation detail., In addition to these operational analysis principles for requirements, engineering:, • Understand the problem before you begin to create the analysis model., • Develop prototype that enable a user to understand how, human/machine interaction will occur., • Record the origin of and the reason for every requirement., • Use multiple views of requirements., • Rank requirements., • Work to eliminate ambiguity
