SOFTWARE ENGINEERING
|
|
- Marshall Turner
- 6 years ago
- Views:
Transcription
1 Page 1 MCA302 SOFTWARE ENGINEERING UNIT I - SOFTWARE PROCESS Introduction S/W Engineering Paradigm life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, object oriented) - system engineering computer based system verification validation life cycle process development process system engineering hierarchy. References: 1. Roger S. Pressman, Software Engineering A Practitioners Approach, Sixth Edition, McGraw Hill, Ian Sommerville, Software Engineering, 7th edition, Pearson Education NPTEL Material-IIT Kharagpur Soft%20Engg/pdf/m01L01.pdf Compiled By: A.Saleem Raja. MCA.,M.Phil.,(M.Tech) & R.Vinodini.MCA.,M.Phil., Lecturer Department of MCA
2 Page 2 MCA302 Objective At the end of this unit, students will learn Computer Software Software Engineering Software Process Software Process Model Software Life Cycle Introduction Software engineering is an engineering approach for software development. We can alternatively view it as a systematic collection of past experience. The experience is arranged in the form of methodologies and guidelines. A small program can be written without using software engineering principles. But if one wants to develop a large software product, then software engineering principles are indispensable to achieve a good quality software cost effectively. Need for software engineering principles Without using software engineering principles it would be difficult to develop large programs. In industry it is usually needed to develop large programs to accommodate multiple functions. A problem with developing such large commercial programs is that the complexity and difficulty levels of the programs increase exponentially. For example, a program of size 1,000 lines of code has some complexity. But a program with 10,000 LOC is not just 10 times more difficult to develop, but may as well turn out to be 100 times more difficult unless software engineering principles are used. In such situations software engineering techniques come to rescue. Software engineering helps to reduce the programming complexity. Software engineering principles use two important techniques to reduce problem complexity: abstraction and decomposition. Abstraction: The principle of abstraction (in fig.1.4) implies that a problem can be simplified by omitting irrelevant details. In other words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant for certain purpose and
3 Page 3 MCA302 suppress other aspects that are not relevant for the given purpose. Once the simpler problem is solved, then the omitted details can be taken into consideration to solve the next lower level abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the problem. Decomposition: The other approach to tackle problem complexity is decomposition. In this technique, a complex problem is divided into several smaller problems and then the smaller problems are solved one by one. The problem has to be decomposed such that each component of the decomposed problem can be solved independently and then the solution of the different components can be combined to get the full solution. A good decomposition of a problem should minimize interactions among various components. Software Software is defined by-roger S. Pressman Computer software is the product that software engineers design and build. It encompasses programs that execute within a computer of any size and architecture, documents that encompass hard-copy and virtual forms, and data that combine numbers and text but also includes representations of pictorial, video, and audio information. Software is defined by- Ian Sommerville
4 Page 4 MCA302 Computer programs and associated documentation such as requirements, design models and user manuals. 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 Example: PC software such as Excel or Word. Bespoke (custom) - developed for a single customer according to their specification. New software can be created by developing new programs, configuring generic software systems or reusing existing software. Software Characteristics Software is a logical rather than a physical system element. Therefore, software has characteristics that are considerably different than those of hardware: 1. Software is developed or engineered; it is not manufactured in the classical sense. 2. Software doesn't "wear out." 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, software maintenance involves considerably more complexity than hardware maintenance. 3. Although the industry is moving toward component-based assembly, most software continues to be custom built. Generic categories for software applications Software may be applied in any situation for which a pre-specified set of procedural steps (i.e., an algorithm) has been defined. The following software areas indicate the breadth of potential applications:
5 Page 5 MCA302 System software. System software is a collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) process complex, but determinate, information structures. The system software area 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. Real-time software. Software that monitors/analyzes/controls real-world events as they occur is called real time. Elements of real-time software include a data gathering component that collects and formats information from an external environment, an analysis component that transforms information as required by the application, a control/output component that responds to the external environment, and a monitoring component that coordinates all other components so that real-time response (typically ranging from 1 millisecond to 1 second) can be maintained. Business software. Business information processing is the largest single software application area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inventory) have evolved into management information system (MIS) software that accesses one or more large databases containing business information. Engineering and scientific software. Engineering and scientific software have been characterized by "number crunching" algorithms. Applications range from astronomy to volcanology, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing. Embedded software. Intelligent products have become commonplace in nearly every consumer and industrial market. Embedded software resides in read-only memory and is used to control products and systems for the consumer and industrial markets. Embedded software can perform very limited and esoteric functions (e.g., keypad control for a microwave oven) or provide significant function and control
6 Page 6 MCA302 capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems). Personal computer software. The personal computer software market has burgeoned over the past two decades. Word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business financial applications, external network, and database access are only a few of hundreds of applications. Web-based software. The Web pages retrieved by a browser are software that incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g., hypertext and a variety of visual and audio formats). In essence, the network becomes a massive computer providing an almost unlimited software resource that can be accessed by anyone with a modem. Artificial intelligence software. Artificial intelligence (AI) software makes use of non-numerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Expert systems, also called knowledge based systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing are representative of applications within this category. Software Engineering There are hundreds of authors have developed personal definitions of software engineering. The IEEE [IEE93] has developed a more comprehensive definition when it states: 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). Another definition by - Ian Sommerville Software engineering is an engineering discipline that is concerned with all aspects of software production.
7 Page 7 MCA302 Software engineers should adopt a systematic and organized approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available. The advantages of using software engineering for developing software are: Improved quality Improved requirement specification Improved cost and schedule estimates Better use of automated tools and techniques Less defects in final product Better maintenance of delivered software Well defined processes Improved productivity Improved reliability What is the difference between software engineering and computer science? Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. Computer science theories are still insufficient to act as a complete underpinning for software engineering (unlike e.g. physics and electrical 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 process concerned with developing the software infrastructure, control, applications and databases in the system. System engineers are involved in system specification, architectural design, integration and deployment. Software Engineering Layers (Process, Methods, and Tools)
8 Page 8 MCA302 o Software engineering is a layered technology. Referring to below figure, any engineering approach (including software engineering) must rest on an organizational commitment to quality. Figure: Software engineering layers o The foundation for software engineering is the process layer. Software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. The key process areas form the basis for management control of software projects and establish the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed. o Software engineering methods 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. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques. o Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another. Generic Phases in Software Engineering The work associated with software engineering can be categorized into three generic phases, regardless of application area, project size, or complexity. The definition phase focuses on what. That is, during definition, the software engineer attempts to identify what information is to be processed, what function and performance
9 Page 9 MCA302 are desired, what system behavior can be expected, what interfaces are to be established, what design constraints exist, and what validation criteria are required to define a successful system. The development phase focuses on how. That is, during development a software engineer attempts to define how data are to be structured, how function is to be implemented within a software architecture, how procedural details are to be implemented, how interfaces are to be characterized, how the design will be translated into a programming language (or nonprocedural language), and how testing will be performed. The methods applied during the development phase will vary, but three specific technical tasks should always occur: software design, code generation, and software testing. The support phase focuses on change associated with error correction, adaptations required as the software's environment evolves, and changes due to enhancements brought about by changing customer requirements. Software process Software process is a series of predictable steps a road map that helps to create a timely, high-quality product or system (or) a set of activities whose goal is the development or evolution of software. Generic activities in all software processes are: o Specification - what the system should do and its development constraints o Development - production of the software system o Validation - checking that the software is what the customer wants o Evolution - changing the software in response to changing demands. Capability Maturity Model (CMM) In recent years, there has been a significant emphasis on process maturity. The Software Engineering Institute (SEI) has developed a comprehensive model predicated on a set of software engineering capabilities that should be present as organizations reach different levels of process maturity. To determine an organization s current state of process maturity, the SEI uses an assessment that results in a five point grading scheme. The grading scheme
10 Page 10 MCA302 determines compliance with a capability maturity model (CMM) that defines key activities required at different levels of process maturity. Software Process Models (Or) Software Engineering Paradigm A development strategy that encompasses the process, methods, and tools layers and the generic phases. This strategy is often referred to as a process model or a software engineering paradigm. (Or) A simplified representation of a software process, presented from a specific perspective. Examples of process perspectives are o Workflow perspective - sequence of activities; o Data-flow perspective - information flow; o Role/action perspective - who does what. Generic process models o Waterfall o Iterative development o Component-based software engineering. A process model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required. Software Life Cycle Model
11 Page 11 MCA302 A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle. A life cycle model represents all the activities required to make a software product transit through its life cycle phases. It also captures the order in which these activities are to be undertaken. In other words, a life cycle model maps the different activities performed on a software product from its inception to retirement. Different life cycle models may map the basic development activities to phases in different ways. Thus, no matter which life cycle model is followed, the basic activities are included in all life cycle models though the activities may be carried out in different orders in different life cycle models. During any life cycle phase, more than one activity may also be carried out. For example, the design phase might consist of the structured analysis activity followed by the structured design activity. The need for a software life cycle model The development team must identify a suitable life cycle model for the particular project and then adhere to it. Without using of a particular life cycle model the development of a software product would not be in a systematic and disciplined manner. When a software product is being developed by a team there must be a clear understanding among team members about when and what to do. Otherwise it would lead to chaos and project failure. A software life cycle model defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So without software life cycle model the entry and exit criteria for a phase cannot be recognized. Without software life cycle models (such as classical waterfall model, iterative waterfall model, prototyping model, evolutionary model, spiral model etc.) it becomes difficult for software project managers to monitor the progress of the project. Different software life cycle models Linear sequential model (or) Waterfall Model Prototyping model Rad model
12 Page 12 MCA302 Evolutionary software process models Incremental model Spiral model WinWin spiral model Concurrent development model Component-based development Formal methods model Fourth generation techniques Linear Sequential Model (or) Waterfall Model Sometimes called the classic life cycle or the waterfall model, the linear sequential model suggests a systematic, sequential approach5 to software development that begins at the system level and progresses through analysis, design, coding, testing, and support Classical waterfall model divides the life cycle into the following phases as shown in figure o o o o o o Feasibility Study Requirements Analysis and Specification Design Coding and Unit Testing Integration and System Testing Maintenance
13 Page 13 MCA302 Figure: Classical Waterfall Model Activities in each phase of the life cycle Activities undertaken during feasibility study: - The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product. At first project managers or team leaders try to have a rough understanding of what is required to be done by visiting the client side. They study different input data to the system and output data to be produced by the system. They study what kind of processing is needed to be done on these data and they look at the various constraints on the behavior of the system. After they have an overall understanding of the problem they investigate the different solutions that are possible. Then they examine each of the solutions in terms of what kind of resources required, what would be the cost of development and what would be the development time for each solution.
14 Page 14 MCA302 Based on this analysis they pick the best solution and determine whether the solution is feasible financially and technically. They check whether the customer budget would meet the cost of the Activities undertaken during requirements analysis and specification: - The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely Requirements gathering and analysis Requirements specification The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed. This is done to clearly understand the customer requirements so that incompleteness and inconsistencies are removed. The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. For example, to perform the requirements analysis of a business accounting software required by an organization, the analyst might interview all the accountants of the organization to ascertain their requirements. The data collected from such a group of users usually contain several contradictions and ambiguities, since each user typically has only a partial and incomplete view of the system. Therefore it is necessary to identify all ambiguities and contradictions in the requirements and resolve them through further discussions with the customer. After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements properly understood, the requirements specification activity can start. During this activity, the user requirements are systematically organized into a Software Requirements Specification (SRS) document.
15 Page 15 MCA302 The customer requirements identified during the requirements gathering and analysis activity are organized into a SRS document. The important components of this document are functional requirements, the nonfunctional requirements, and the goals of implementation. Activities undertaken during design: - The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the software architecture is derived from the SRS document. Two distinctly different approaches are available: the traditional design approach and the object-oriented design approach. Traditional design approach Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. This is followed by a structured design activity. During structured design, the results of structured analysis are transformed into the software design. Object-oriented design approach In this technique, various objects that occur in the problem domain and the solution domain are first identified, and the different relationships that exist among these objects are identified. The object structure is further refined to obtain the detailed design. Activities undertaken during coding and unit testing:- The purpose of the coding and unit testing phase (sometimes called the implementation phase) of software development is to translate the software design into source code. Each component of the design is implemented as a program module. The end-product of this phase is a set of program modules that have been individually tested.
16 Page 16 MCA302 During this phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage. Activities undertaken during integration and system testing: - Integration of different modules is undertaken once they have been coded and unit tested. During the integration and system testing phase, the modules are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document. System testing usually consists of three different kinds of testing activities: α testing: It is the system testing performed by the development team. β testing: It is the system testing performed by a friendly set of customers. acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product. System testing is normally carried out in a planned manner according to the system test plan document. The system test plan identifies all testing-related activities that must be performed, specifies the schedule of testing, and allocates resources. It also lists all the test cases and the expected outputs for each test case. Activities undertaken during maintenance: - Maintenance of a typical software product requires much more than the effort necessary to develop the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in the 40:60 ratio.
17 Page 17 MCA302 Maintenance involves performing any one or more of the following three kinds of activities: o Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. o Improving the implementation of the system, and enhancing the functionalities of the system according to the customer s requirements. This is called perfective maintenance. o Porting the software to work in a new environment. For example, porting may be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance. Problems of the classical waterfall model The main drawback of the waterfall model is Difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase. Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. Phase-entry and Phase-exit criteria of each phase At the starting of the feasibility study, project managers or team leaders try to understand what the actual problem is by visiting the client side. At the end of that phase they pick the best solution and determine whether the solution is feasible financially and technically. At the starting of requirements analysis and specification phase the required data is collected. After that requirement specification is carried out. Finally, SRS document is produced.
18 Page 18 MCA302 At the starting of design phase, context diagram and different levels of DFDs are produced according to the SRS document. At the end of this phase module structure (structure chart) is produced. During the coding phase each module (independently compilation unit) of the design is coded. Then each module is tested independently as a stand-alone unit and debugged separately. After this each module is documented individually. The end product of the implementation phase is a set of program modules that have been tested individually but not tested together. After the implementation phase, different modules which have been tested individually are integrated in a planned manner. After all the modules have been successfully integrated and tested, system testing is carried out. Software maintenance denotes any changes made to a software product after it has been delivered to the customer. Maintenance is inevitable for almost any kind of product. Prototyping Paradigm A prototype usually turns out to be a very crude version of the actual system. The prototyping paradigm begins with requirements gathering. Developer and customer meet and define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A "quick design" then occurs. The quick design focuses on a representation of those aspects of the software that will be visible to the customer/user (e.g., input approaches and output formats). The quick design leads to the construction of a prototype. The prototype is evaluated by the customer/user and used to refine requirements for the software to be developed. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done. Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is built, the developer attempts to use existing program fragments or
19 Page 19 MCA302 applies tools (e.g., report generators, window managers) that enable working programs to be generated quickly. Figure: Prototyping paradigm Need for a prototype in software development There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the customer s needs: How the screens might look like How the user interface would behave How the system would produce outputs This is something similar to what the architectural designers of a building do; they show a prototype of the building to their customer. The customer can evaluate whether he likes it or not and the changes that he would need in the actual product. A similar thing happens in the case of a software product and its prototyping model. Another reason for developing a prototype is that it is impossible to get the perfect product in the first attempt. Many researchers and engineers advocate that if you want to develop a
20 Page 20 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & good product you must plan to throw away the first version. The experience gained in developing the prototype can be used to develop the final product. A prototyping model can be used when technical solutions are unclear to the development team. A developed prototype can help engineers to critically examine the technical issues associated with the product development. Often, major design decisions depend on issues like the response time of a hardware controller, or the efficiency of a sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way to resolve the technical issues. Examples for prototype model A prototype of the actual product is preferred in situations such as: User requirements are not complete Technical issues are not clear Let s see an example for each of the above category. Example 1: User requirements are not complete In any application software like billing in a retail shop, accounting in a firm, etc the users of the software are not clear about the different functionalities required. Once they are provided with the prototype implementation, they can try to use it and find out the missing functionalities. Example 2: Technical issues are not clear Suppose a project involves writing a compiler and the development team has never written a compiler. In such a case, the team can consider a simple language, try to build a compiler in order to check the issues that arise in the process and resolve them. After successfully building a small compiler (prototype), they would extend it to one that supports a complete language.
21 Page 21 MCA302 RAD Model Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a highspeed adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a fully functional system within very short time periods (e.g., 60 to 90 days). Used primarily for information systems applications, the RAD approach encompasses the following phases: Business modeling: The information flow among business functions is modeled. Data modeling: The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics (called attributes) of each object are identified and the relationships between these objects defined.
22 Page 22 MCA302 Process modeling: The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object. Application generation: RAD assumes the use of fourth generation techniques rather than creating software using conventional third generation programming languages, the RAD process works to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software. Testing and turnover: Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully exercised. Problems with RAD Model For large but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams. RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a system complete in a much abbreviated time frame. If commitment is lacking from either constituency, RAD projects will fail. Not all types of applications are appropriate for RAD. If a system cannot be properly modularized, building the components necessary for RAD will be problematic. If high performance is an issue and performance is to be achieved through tuning the interfaces to system components, the RAD approach may not work. RAD is not appropriate when technical risks are high. This occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability with existing computer programs. Evolutionary Software Process Models There is growing recognition that software, like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds,
23 Page 23 MCA302 making a straight path to an end product unrealistic; tight market deadlines make completion of a comprehensive software product impossible, but a limited version must be introduced to meet competitive or business pressure; a set of core product or system requirements is well understood, but the details of product or system extensions have yet to be defined. In these and similar situations, software engineers need a process model that has been explicitly designed to accommodate a product that evolves over time. The linear sequential model is designed for straight-line development. In essence, this waterfall approach assumes that a complete system will be delivered after the linear sequence is completed. The prototyping model is designed to assist the customer (or developer) in understanding requirements. In general, it is not designed to deliver a production system. The evolutionary nature of software is not considered in either of these classic software engineering paradigms. Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software. Evolutionary software models are Incremental model Spiral model WinWin spiral model Concurrent development model Incremental Model The incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping. Referring to Figure 1, the incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces a deliverable increment of the software. For example, word-processing software developed using the incremental paradigm might deliver basic file management, editing, and document production functions in the first increment; more sophisticated editing and document production capabilities in the second
24 Page 24 MCA302 increment; spelling and grammar checking in the third increment; and advanced page layout capability in the fourth increment. It should be noted that the process flow for any increment can incorporate the prototyping paradigm. Figure 1: The incremental model When an incremental model is used, the first increment is often a core product. That is, basic requirements are addressed, but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer (or undergoes detailed review). As a result of use and/or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced. The incremental process model, like prototyping and other evolutionary approaches, is iterative in nature. But unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment. Early increments are stripped down versions of the final product, but they do provide capability that serves the user and also provide a platform for evaluation by the user.
25 Page 25 MCA302 Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project. Early increments can be implemented with fewer people. If the core product is well received, then additional staff (if required) can be added to implement the next increment. In addition, increments can be planned to manage technical risks. For example, a major system might require the availability of new hardware that is under development and whose delivery date is uncertain. It might be possible to plan early increments in a way that avoids the use of this hardware, thereby enabling partial functionality to be delivered to end-users without inordinate delay. Spiral model The spiral model, originally proposed by Boehm, is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. It provides the potential for rapid development of incremental versions of the software. Using the spiral model, software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. A spiral model is divided into a number of framework activities, also called task regions. Typically, there are between three and six task regions. Figure 2 depicts a spiral model that contains six task regions:
26 Page 26 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & Figure 2 A typical spiral model Customer communication tasks required to establish effective communication between developer and customer. Planning tasks required to define resources, timelines, and other project related information. Risk analysis tasks required to assess both technical and management risks. Engineering tasks required to build one or more representations of the application. Construction and release tasks required to construct, test, install, and provide user support (e.g., documentation and training). Customer evaluation tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.
27 Page 27 MCA302 As this evolutionary process begins, the software engineering team moves around the spiral in a clockwise direction, beginning at the center. The first circuit around the spiral might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from customer evaluation. In addition, the project manager adjusts the planned number of iterations required to complete the software. The spiral model is a realistic approach to the development of large-scale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism but, more important, enables the developer to apply the prototyping approach at any stage in the evolution of the product. It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into an iterative framework that more realistically reflects the real world. The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic. But like other paradigms, the spiral model may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur. Finally, the model has not been used as widely as the linear sequential or prototyping paradigms. It will take a number of years before efficacy of this important paradigm can be determined with absolute certainty. WinWin Spiral Model This is an adaptation of the spiral model which emphasis is explicitly placed on the involvement of the client in a negotiation process at the genesis of the product
28 Page 28 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & development. Ideally, the developer would simply ask the customer what is required and the customer would provide sufficient detail to proceed. Unfortunately this rarely happens and significant negotiations between both parties are required to balance functionality, performance, etc with cost and time-to-market considerations. The model, shown in Fig. 3, derives its name from the objective of these negotiations, i.e. win-win. The client gets the product that satisfies the majority of his/her needs, and the developer wins by working to realistic and achievable budgets and deadlines. To achieve this objective the model defines a set of negotiation activities at the beginning of each pass around the spiral. Rather than a single customer communication activity the following activities are defined: Identification of the system stakeholders. That is the people on the organisation that have direct business interest in the product to be built and will be rewarded for a successful outcome or criticised if the effort fails (e.g. user, customer, developer, maintainer, interfacer, etc.). Determination of the stakeholder s win conditions Negotiations of the stakeholder s win conditions to reconcile them into a set of winwin conditions for all concerned (including the software project team).
29 Page 29 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & Figure 3: WINWIN Spiral Model In addition to the early emphasis placed on the win-win condition, the model also introduces three process milestones (anchor points), which help establish the completion of one cycle around the spiral and provide the decision milestones before the software project proceeds. These are, 1. Life Cycle Objectives (LCO) Defines a set of objectives for each major software activity (e.g. a set of objectives associated with the definition of top level product requirements) 2. Life Cycle Architecture (LCA) Establishes the objectives that must be met as the as the software architecture is defined. 3. Initial Operational Capability (IOC) represents a set of objectives associated with the preparation of the software for installation/distribution, site preparations prior to installations, and assistance required by all parties that will use or support the software.
30 Page 30 MCA302 TECHNOLOGY CHETTINAD COLLEGE OF ENGINEERING & Advantages: Faster software production facilitated through collaborative involvement of the relevant stake holders. Cheaper software via rework and maintenance reductions Component Based Software Engineering In the majority of software projects, there is some software reuse. This usually happens informally when people working on the project know of designs or code which is similar to that required. They look for these, modify them as needed and incorporate them into their system. This informal reuse takes place irrespective of the development process that is used. However, in the last few years, an approach to software development called component-based software engineering (CBSE), which relies on reuse, has emerged and is becoming increasingly used. This reuse-oriented approach relies on a large base of reusable software components and some integrating framework for these components. Sometimes, these components are systems in their own right (COTS or commercial off-the-shelf systems) that may provide specific functionality such as text formatting or numeric calculation. The generic process model for CBSE is shown in Figure 3. Figure 3 Component-based software engineering While the initial requirements specification stage and the validation stage are comparable with other processes, the intermediate stages in a reuse-oriented process are different. These stages are:
31 Page 31 MCA Component analysis. Given the requirements specification, a search is made for components to implement that specification. Usually, there is no exact match, and the components that may be used only provide some of the functionality required. 2. Requirements modification. During this stage, the requirements are analyzed using information about the components that have been discovered. They are then modified to reflect the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions. 3. System design with reuse. During this phase, the framework of the system is designed or an existing framework is reused. The designers take into account the components that are reused and organize the framework to cater to this. Some new software may have to be designed if reusable components are not available. 4. Development and integration Software that cannot be externally procured is developed, and the components and COTS systems are integrated to create the new system. System integration, in this model, may be part of the development process rather than a separate activity. Component-based software engineering has the obvious advantage of reducing the amount of software to be developed and so reducing cost and risks. It usually also leads to faster delivery of the software. However, requirements compromises are inevitable and this may lead to a system that does not meet the real needs of users. Furthermore, some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them. System Engineering: Software engineering occurs as a consequence of system engineering System engineering may take on two different forms depending on the application domain
32 Page 32 MCA302 Business process engineering conducted when the context of the work focuses on a business enterprise Product engineering conducted when the context of the work focuses on a product that is to be built Both forms bring order to the development of computer-based systems Both forms work to allocate a role for computer software and to establish the links that tie software to other elements of a computer-based system System A set or arrangement of things so related as to form a unity or organic whole A set of facts, principles, rules. etc., to show a logical plan linking the various parts A method or plan of classification or arrangement An established way of doing something such as a method or procedure Computer-based System Defined: A set or arrangement of elements that are organized to accomplish some predefined goal by processing information The goal may be to support some business function or to develop a product that can be sold to generate business revenue A computer-based system makes use of system elements Elements constituting one system may represent one macro element of a still larger system Example A factory automation system may consist of a numerical control machine, robots, and data entry devices; each can be its own system At the next lower hierarchical level, a manufacturing cell is its own computerbased system that may integrate other macro elements The role of the system engineer is to define the elements of a specific computerbased system in the context of the overall hierarchy of systems
33 Page 33 MCA302 A computer-based system makes use of the following four system elements that combine in a variety of ways to transform information Software: computer programs, data structures, and related work products that serve to effect the logical method, procedure, or control that is required Hardware: electronic devices that provide computing capability, interconnectivity devices that enable flow of data, and electromechanical devices that provide external functions People: Users and operators of hardware and software Database: A large, organized collection of information that is accessed via software and persists over time The uses of these elements are described in the following: Documentation: Descriptive information that portrays the use and operation of the system Procedures: The steps that define the specific use of each system element or the procedural context in which the system resides Verification and validation Software testing is one element of a broader topic that is often referred to as Verification and validation (V&V). Verification refers to the set of activities that ensure that software correctly implements a specific function. Validation refers to a different set of activities ensure that the software that has been built is traceable to customer requirements. Verification: Are we building the product right? Validation: Are we building the right product? The definition of V&V encompasses many of the activities that we have referred to as software quality assurance (SQA).
Introduction to Software Engineering
UNIT I SOFTWARE PROCESS Introduction S/W Engineering Paradigm life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, objects oriented) -system engineering computer
More informationDarshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1
Failure Rate Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1 SOFTWARE (What is Software? Explain characteristics of Software. OR How the software product is differing than
More informationII-IT IV-SEM. 1. Software product and process. Software Engineering and Quality Assurance. Objectives:
II-IT IV-SEM Software Engineering and Quality Assurance 1. Software product and process Objectives: To introduce software engineering and to explain its importance. To set out the answers to key questions
More informationPertemuan 2. Software Engineering: The Process
Pertemuan 2 Software Engineering: The Process Collect Your Project Topic What is Software Engineering? Software engineering is the establishment and sound engineering principles in order to obtain economically
More informationSoftware Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1
Software Processes Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be
More informationLectures 2 & 3. Software Processes. Software Engineering, COMP201 Slide 1
Lectures 2 & 3 Software Processes Software Engineering, COMP201 Slide 1 What is a Process? When we provide a service or create a product we always follow a sequence of steps to accomplish a set of tasks
More informationSoftware Processes. Objectives. Topics covered. The software process. Waterfall model. Generic software process models
Objectives Software Processes To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
More informationSoftware Engineering. Unit 1. Software Process
1 Unit 1 Software Process Software: a) Instructions (Computer Programs) that when executed provide desired features, function, and performance. b) Data structures that enable the programs to adequately
More informationObjectives. The software process. Topics covered. Waterfall model. Generic software process models. Software Processes
Objectives Software Processes To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
More informationBased on Software Engineering, by Ian Sommerville Coherent sets of activities for specifying, designing, implementing and testing software systems
Software Processes Based on Software Engineering, by Ian Sommerville Coherent sets of activities for specifying, designing, implementing and testing software systems Slide 1 Objectives To introduce software
More informationLecture 1. In practice, most large systems are developed using a. A software process model is an abstract representation
Chapter 2 Software Processes Lecture 1 Software process descriptions When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing
More informationSoftware Processes 1
Software Processes 1 Topics covered Software process models Process activities Coping with change 2 The software process A structured set of activities required to develop a software system. Many different
More informationThe software process
Software Processes The software process A structured set of activities required to develop a software system Specification; Design; Validation; Evolution. A software process model is an abstract representation
More informationTopics covered. Software process models Process iteration Process activities The Rational Unified Process Computer-aided software engineering
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
More informationChapter 3 Prescriptive Process Models
Chapter 3 Prescriptive Process Models - Generic process framework (revisited) - Traditional process models - Specialized process models - The unified process Generic Process Framework Communication Involves
More informationII. Software Life Cycle. Laurea Triennale in Informatica Corso di Ingegneria del Software I A.A. 2006/2007 Andrea Polini
II. Software Life Cycle Laurea Triennale in Informatica Corso di Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process
More informationSoftware Engineering
Software Engineering Part I. Aspects and Models of Software Development Process Gunadarma University 1 Software Engineering Outline 1 Introduction 2 Aspects of Software Engineering Software Engineering
More informationSoftware Engineering
Software Engineering (CS550) Software Development Process Jongmoon Baik Software Development Processes (Lifecycle Models) 2 What is a S/W Life Cycle? The series of stages in form and functional activity
More informationChapter 3 Software Process Model
Usman Akram COMSATS Institute of information Technology lahore musmanakram@ciitlahore.edu.pk March 8, 2015 About software process model Outline 1 About software process model Build and Fix Model Why Models
More informationCLASS/YEAR: II MCA SUB.CODE&NAME: MC7303, SOFTWARE ENGINEERING. 1. Define Software Engineering. Software Engineering: 2. What is a process Framework? Process Framework: UNIT-I 2MARKS QUESTIONS AND ANSWERS
More informationA Comparative Study on Software Development Life Cycle Models
A Comparative Study on Software Development Life Cycle Models Prof. Supriya Madhukar Salve 1, Prof. Syed Neha Samreen 2, Prof. Neha Khatri-Valmik 3 123Assistant Professor, Dept. of Computer Science and
More informationSystem and Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1
System and Software Engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 Objectives To introduce software engineering and to explain its importance To set out the answers
More informationNote 10: Software Process
Computer Science and Software Engineering University of Wisconsin - Platteville Note 10: Software Process Yan Shi Lecture Notes for SE 3330 UW-Platteville Based on Pressman Chapter 2 & 3 Software Process
More informationDEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Software Engineering Third Year CSE( Sem:I) 2 marks Questions and Answers
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Software Engineering Third Year CSE( Sem:I) 2 marks Questions and Answers UNIT 1 1. What are software myths Answer: Management myths: We already have a book
More informationCMSC 435: Software Engineering Section Back to Software. Important: Team Work. More Resources
CMSC 435: Software Engineering Section 0101! Atif M. Memon (atif@cs.umd.edu)! 4115 A.V.Williams building! Phone: 301-405-3071! Office hours!.tu.th. (10:45am-12:00pm)! Don t wait, don t hesitate, do communicate!!!
More informationSoftware Engineering COMP 201
Software Engineering COMP 201 Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Lecture 2 Software Processes
More informationSWE 211 Software Processes
SWE 211 Software Processes These slides are designed and adapted from slides provided by Software Engineering 9 /e Addison Wesley 2011 by Ian Sommerville 1 Outlines Software process models Process activities
More informationSDLC AND MODEL SELECTION: A STUDY
SDLC AND MODEL SELECTION: A STUDY V. Therese Clara Asst professor of Computer Science, Madurai Kamaraj University College, Madurai, India ABSTRACT In the software industry, the frequency of failure of
More informationVolume 8, No. 1, Jan-Feb 2017 International Journal of Advanced Research in Computer Science RESEARCH PAPER Available Online at
Volume 8, No. 1, Jan-Feb 2017 International Journal of Advanced Research in Computer Science RESEARCH PAPER Available Online at www.ijarcs.info A Study of Software Development Life Cycle Process Models
More informationIntroduction to Software Engineering
CHAPTER 1 Introduction to Software Engineering Structure 1.1 Introduction Objectives 1.2 Basics of Software Engineering 1.3 Principles of Software Engineering 1.4 Software Characteristics 1.5 Software
More informationA New Divide & Conquer Software Process Model
A New Divide & Conquer Software Process Model First A. Hina Gull, Second B. Farooque Azam Third C. Wasi Haider Butt, Fourth D. Sardar Zafar Iqbal Abstract The software system goes through a number of stages
More informationSelecting Software Development Life Cycles. Adapted from Chapter 4, Futrell
Selecting Software Development Life Cycles Adapted from Chapter 4, Futrell Examples of Software Life Cycle Models Classical Waterfall Waterfall with feedback V-Shaped Prototyping Incremental Spiral Rapid
More informationSoftware Engineering Part 2
CS 0901341 Software Engineering Part 2 In this part, we look at 2.1 Software Process 2.2 Software Process Models 2.3 Tools and Techniques for Processing Modelling As we saw in the previous part, the concept
More informationSolutions Manual. Object-Oriented Software Engineering. An Agile Unified Methodology. David Kung
2 David Kung Object-Oriented Software Engineering An Agile Unified Methodology Solutions Manual 3 Message to Instructors July 10, 2013 The solutions provided in this manual may not be complete, or 100%
More informationIntroduction to Systems Analysis and Design
Introduction to Systems Analysis and Design What is a System? A system is a set of interrelated components that function together to achieve a common goal. The components of a system are called subsystems.
More informationA Comparison Between Evolutionary and Prototype Model
A Comparison Between Evolutionary and Prototype Model Aditi Thakur Department of Computer Science, Baddi University of Emerging Sciences and Technology ABSTRACT: In this paper, I have examined a number
More informationCourse Organization. Lecture 1/Part 1
Course Organization Lecture 1/Part 1 1 Outline About me About the course Lectures Seminars Evaluation Literature 2 About me: Ing. RNDr. Barbora Bühnová, Ph.D. Industrial experience Research Quality of
More informationSoftware Architecture and Design Patterns
Software Architecture and Design Patterns MODULE I Define Software: Computer software is the product that software engineers design and build. It encompasses programs that execute within a computer of
More informationCOSC 735: Software Engineering Test 1 Sample Solution
COSC 735: Software Engineering Test 1 Sample Solution QUESTION 1: 1. (a) Define Software Engineering. Software engineering is the establishment and use of sound engineering principles in order to obtain
More informationChapter 3. Information Systems Development. McGraw-Hill/Irwin. Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Chapter 3 Information Systems Development McGraw-Hill/Irwin Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Objectives 3-2 Describe the motivation for a system development process
More informationPlanning and the Software Lifecycle. CSCE Lecture 2-08/26/2015
Planning and the Software Lifecycle CSCE 740 - Lecture 2-08/26/2015 Today s Goals Introduce software development processes Definitions - processes and process models Choosing a process AKA: planning and
More informationIntroduction to Software Engineering
Introduction to Software Engineering 2. Requirements Collection Mircea F. Lungu Based on a lecture by Oscar Nierstrasz. Roadmap > The Requirements Engineering Process > Functional and non-functional requirements
More information7. Model based software architecture
UNIT - III Model based software architectures: A Management perspective and technical perspective. Work Flows of the process: Software process workflows, Iteration workflows. Check Points of The process
More informationversion NDIA CMMI Conf 3.5 SE Tutorial RE - 1
Requirements Engineering SE Tutorial RE - 1 What Are Requirements? Customer s needs, expectations, and measures of effectiveness Items that are necessary, needed, or demanded Implicit or explicit criteria
More informationSoftware Modeling & Analysis. - Fundamentals of Software Engineering - Software Process Model. Lecturer: JUNBEOM YOO
Software Modeling & Analysis - Fundamentals of Software Engineering - Software Process Model Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr What is Software Engineering? [ IEEE Standard 610.12-1990 ] Software
More information03. Perspective Process Models
03. Perspective Process Models Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 Prescriptive Process Models advocates an orderly approach to software
More informationExplore Comparative Analysis Software Development Life Cycle Models
Explore Comparative Analysis Software Development Life Cycle Models Anshu Mishra Assistant Professor, Department of Information Science and Engineering Jyothy Institute of Technology, Bangalore Abstract-The
More informationSHRI ANGALAMMAN COLLEGE OF ENGINEERING & TECHNOLOGY (An ISO 9001:2008 Certified Institution) SIRUGANOOR,TRICHY
SHRI ANGALAMMAN COLLEGE OF ENGINEERING & TECHNOLOGY (An ISO 9001:2008 Certified Institution) SIRUGANOOR,TRICHY-621105. DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS1301- SOFTWARE ENGINEERING UNIT I
More informationIntroduction to Software Life Cycles. CSCI 5828: Foundations of Software Engineering Lecture 06 09/08/2016
Introduction to Software Life Cycles CSCI 5828: Foundations of Software Engineering Lecture 06 09/08/2016 1 Goals Present an introduction to the topic of software life cycles concepts and terminology benefits
More informationCSE 435 Software Engineering. Sept 14, 2015
CSE 435 Software Engineering Sept 14, 2015 What is Software Engineering Where Does the Software Engineer Fit In? Computer science: focusing on computer hardware, compilers, operating systems, and programming
More informationSoftware configuration management
Software configuration management Bởi: Hung Vo Introduction A system can be defined as a collection of components organized to accomplish a specific function or set of functions. The configuration of a
More informationChapter 6. Software Quality Management & Estimation
Chapter 6 Software Quality Management & Estimation What is Quality Management Also called software quality assurance (SQA) s/w quality:- It is defined as the degree to which a system, components, or process
More informationGlobal Journal of Engineering Science and Research Management
SW REQUIREMENT ENGINEERING IN PRACTICE Smita Raj* * C-204, Shiksha Niketan, Vasundhara, Sec-5, Ghaziabad 201012 DOI: 10.5281/zenodo.199474 KEYWORDS: Requirement, Requirement engineering, process models,
More information2009 Spring. Software Modeling & Analysis. - Software Process Model. Lecturer: JUNBEOM YOO
2009 Spring Software Modeling & Analysis - Fundamentals of Software Engineering - Software Process Model Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr What is Software Engineering? IEEE Std 610.12-1990 [ IEEE
More informationChapter 4 Software Process and Project Metrics
Chapter 4 Software Process and Project Metrics 1 Measurement & Metrics... collecting metrics is too hard... it's too time-consuming... it's too political... it won't prove anything... Anything that you
More informationA Comparative Study of Universally Accepted SDLC Models for Software Development
2018 IJSRST Volume 4 Issue 5 Print ISSN: 2395-6011 Online ISSN: 2395-602X Themed Section: Science and Technology A Comparative Study of Universally Accepted SDLC Models for Software Development ABSTRACT
More informationThis tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping.
i About the Tutorial SDLC stands for Software Development Life Cycle. SDLC is a process that consists of a series of planned activities to develop or alter the Software Products. This tutorial will give
More information7. Project Management
Subject/Topic/Focus: 7. Project Management Management of Systems Engineering Processes Summary: Project management Systems engineering Maturity model and process improvement Literature: Ian Sommerville:
More informationRequirements Engineering
Requirements Engineering Professor Ray Welland Department of Computing Science University of Glasgow E-mail: ray@dcs.gla.ac.uk The Importance of Requirements Identifying (some) requirements is the starting
More informationABHELSINKI UNIVERSITY OF TECHNOLOGY
T 76.3601 Introduction to Software Engineering Software Life-Cycle Models http://www.soberit.hut.fi/t-76.3601/ Casper.Lassenius@tkk.fi Software Engineering? 1. The application of a systematic, disciplined,
More informationSri Vidya College of Engineering & Technology-Virudhunagar
Sri Vidya College of Engineering &Technology Department of Information Technology Class II Year (04 Semester) Subject Code CS6403 Subject SOFTWARE ENGINEERING Prepared By R.Vidhyalakshmi Lesson Plan for
More informationBCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2
BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 Friday 30 th September 2016 - Morning Answer any THREE questions
More informationBuilding Information Systems
Building Information Systems Content Explain how building new systems produces organizational change. Describe the core activities in the systems development process. Describe the principal methodologies
More informationDigital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016
Digital Industries Apprenticeship: Occupational Brief Software Development Technician September 2016 1 Digital Industries Apprenticeships: Occupational Brief Level 3 Software Development Technician Apprenticeship
More informationSoftware engineering Facts. CSC Compiler Construction Software Engineering Topics. What is software engineering? What is software?
Software engineering Facts CSC 4181 - Compiler Construction Software Engineering Topics Fact: The economies of ALL developed nations are dependent on software. Fact: More and more systems are software
More informationSoftware Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 5 Integrated Object-Oriented Methodologies: USDP and EUP 1 Unified Software Development Process (USDP) Also known as Unified Process (UP)
More informationWhat are requirements? Basics of Requirement Engineering. Definition of a Stakeholder. Stated Vs. Real Requirements. Stated Vs.
What are requirements? Basics of Requirement Engineering Muzaffar Iqbal Farooqi A requirement is a necessary attribute in a system, a statement that identifies a capability, characteristic, or quality
More informationComplex Systems of Systems (CSOS) : Software Benefits,Risks,and Strategies
Complex Systems of Systems (CSOS) : Software Benefits,Risks,and Strategies Barry Boehm, USC Vic Basili, Fraunhofer Maryland SIS Acquisition Conference January 28, 2003 10/22/02 USC-CSE 1 Complex Systems
More informationDigital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016
Digital Industries Apprenticeship: Occupational Brief Software Development Technician September 2016 1 Digital Industries Apprenticeships: Occupational Brief Level 3 Software Development Technician Apprenticeship
More informationThe Systems Development Lifecycle
Modelling and Systems Development Lecture 2 The Systems Development Lifecycle The four-phase model common to all system developments projects The project Major attributes of the Lifecycle Moves systematically
More informationKINGS COLLEGE OF ENGINEERING DEPARTMENT OF INFORMATION TECHNOLOGY QUESTION BANK
KINGS COLLEGE OF ENGINEERING DEPARTMENT OF INFORMATION TECHNOLOGY QUESTION BANK Subject Code & Subject Name: IT1251 Software Engineering and Quality Assurance Year / Sem : II / IV UNIT I SOFTWARE PRODUCT
More informationSDLC Models- A Survey
Available Online at www.ijcsmc.com International Journal of Computer Science and Mobile Computing A Monthly Journal of Computer Science and Information Technology IJCSMC, Vol. 2, Issue. 1, January 2013,
More informationObject-Oriented Software Engineering Practical Software Development using UML and Java. Chapter 11: Managing the Software Process
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 11: Managing the Software Process 11.1 What is Project Management? Project management encompasses all the
More informationIntroduction to Software Life Cycles and Agile. CSCI 5828: Foundations of Software Engineering Lecture 03 09/02/2014
Introduction to Software Life Cycles and Agile CSCI 5828: Foundations of Software Engineering Lecture 03 09/02/2014 1 Goals Present an introduction to the topic of software life cycles concepts and terminology
More informationREQUIREMENTS ENGINEERING
1 REQUIREMENTS ENGINEERING Chapter 4- by Ian Sommerville TOPICS COVERED Functional and non-functional requirements The software requirements document Requirements specification Requirements engineering
More informationRedesigning the Organization with Information Systems
Chapter 14 Redesigning the Organization with Information Systems 14.1 2006 by Prentice Hall OBJECTIVES Demonstrate how building new systems produces organizational change Explain how a company can develop
More informationSoftware Engineering
Software Engineering This book is a part of the course by Jaipur National University, Jaipur. This book contains the course content for Software Engineering. JNU, Jaipur First Edition 2013 The content
More informationSoftware Quality Management
Software Quality Management Minsoo Ryu Hanyang University msryu@hanyang.ac.kr Outline Software Quality Model Software Quality Management Process and Quality Quality Metrics 2 2 What is Quality? Quality,
More informationCMPT 275 Software Engineering
CMPT 275 Software Engineering Software life cycle 1 Software Life Cycle Sequence of processes completed as a software project moves from inception to retirement At beginning of project development, choose
More informationObject-Oriented and Classical Software Engineering
Slide 3.1 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 3 Slide 3.2 THE SOFTWARE PROCESS Overview Slide 3.3
More informationIMPLEMENTATION, EVALUATION & MAINTENANCE OF MIS:
IMPLEMENTATION, EVALUATION & MAINTENANCE OF MIS: The design of a management information system may seem to management to be an expensive project, the cost of getting the MIS on line satisfactorily may
More informationSoftware Development Software Development Activities
Software Development Software Development Activities Problem Definition Requirements Analysis Implementation Planning High-level Design (or Architecture) Detailed Design Coding and Unit Testing (Debugging)
More informationAgile Projects 7. Agile Project Management 21
Contents Contents 1 2 3 4 Agile Projects 7 Introduction 8 About the Book 9 The Problems 10 The Agile Manifesto 12 Agile Approach 14 The Benefits 16 Project Components 18 Summary 20 Agile Project Management
More information7. What is planning? It is an act of formulating a program for a definite course of action. Planning is to decide what is to be done.
UNIT I FUNDAMENTALS 2 MARKS QUESTIONS & ANSWERS 1. What is software project management? Software project management is the art and science of planning and leading software projects. It is sub discipline
More informationRESOLVING APPLICATION DEVELOPMENT ISSUES USING SOA Y. KIRAN KUMAR 1, G.SUJATHA 2, G. JAGADEESH KUMAR 3
RESOLVING APPLICATION DEVELOPMENT ISSUES USING SOA Y. KIRAN KUMAR 1, G.SUJATHA 2, G. JAGADEESH KUMAR 3 1 Asst Professor, Dept of MCA, SVEC, A. Rangampet. ykkumar83@gmail.com, sujatha229@gmail.com,com 148
More informationCourse Information. Course Topics
Course Information Course Topics Software process Requirement analysis Software design Architecture styles Design patterns Unified Modeling Language Software testing Software maintenance SE research topics
More informationChapter 26. Quality Management
Chapter 26 Quality Management - Quality concepts - Software quality assurance - Software reviews - Statistical software quality assurance - Software reliability, availability, and safety - SQA plan (Source:
More informationLecture 2: Software Quality Factors, Models and Standards. Software Quality Assurance (INSE 6260/4-UU) Winter 2016
Lecture 2: Software Quality Factors, Models and Standards Software Quality Assurance (INSE 6260/4-UU) Winter 2016 INSE 6260/4-UU Software Quality Assurance Software Quality Quality Assurance Factors and
More informationCambridge University Press Agile Testing: How to Succeed in an Extreme Testing Environment John Watkins Excerpt More information
1 Introduction If you try to make the software foolproof, they will just invent a better fool! Dorothy Graham 1.1 Why Agile? In today s highly competitive IT business, companies experience massive pressures
More informationOracle Unified Method (OUM) The OUM Implement Core Workflow The Key to Understanding and Applying OUM. An Oracle White Paper April 2012
Oracle Unified Method (OUM) The OUM Implement Core Workflow The Key to Understanding and Applying OUM An Oracle White Paper April 2012 OUM Implement Core Workflow White Paper Introduction... 3 OUM is Iterative...
More informationSoftware Engineering COMP 201
Software Engineering COMP 201 Lecturer: Dr. Igor Potapov Chadwick Building, room 2.09 E-mail: igor@csc.liv.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~igor/comp201 Software Engineering, COMP201
More informationThis document describes the overall software development process of microcontroller software during all phases of the Company Name product life cycle.
Maturity Process Owner Check Release Description Valid Name / Department Name / Department Name / Department Detailed procedure for software development Title: Software Development Procedure Purpose: This
More informationChapter 2 Objectives. Pfleeger and Atlee, Software Engineering: Theory and Practice (edited by B. Cheng) Chapter 2.
Chapter 2 Objectives What we mean by a process Software development products, processes, and resources Several models of the software development process Tools and techniques for process modeling 2.1 The
More informationObject-Oriented and Classical Software Engineering THE SOFTWARE PROCESS 9/17/2017. CHAPTER 3 Slide 3.2. Stephen R. Schach. Overview Slide 3.
Slide 3.1 CHAPTER 3 Slide 3.2 Object-Oriented and Classical Software Engineering THE SOFTWARE PROCESS Eighth Edition, WCB/McGraw-Hill, 2011 Stephen R. Schach Overview Slide 3.3 Overview (contd) Slide 3.4
More informationSlides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman. For non-profit educational use only
Chapter 28 Risk Analysis Slide Set to accompany Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational
More informationCHAPTER 2 LITERATURE SURVEY
10 CHAPTER 2 LITERATURE SURVEY This chapter provides the related work that has been done about the software performance requirements which includes the sub sections like requirements engineering, functional
More informationCS350 Lecture 2 Software Dev. Life Cycle. Doo-Hwan Bae
CS350 Lecture 2 Software Dev. Life Cycle Doo-Hwan Bae bae@se.kaist.ac.kr Whose Drawings? Watts Humphrey, SE is Religion and Philosophy. Just Follow me! CS350 Software Engineering, SoC, KAIST 2 What is
More informationInformation Systems Development
Information Systems Development Based on Chapter 3 of Whitten, Bentley, and Dittman: Systems Analysis and Design for the Global Enterprise (7th Ed). McGraw Hill. 2007 Wei-Tsong Wang 1 IIM, NCKU 3 Objectives
More informationChapter 1. Contents. 1.1 What is Software Engineering! Solving Problems. Objectives. What is Software Engineering
Chapter 1 What is Software Engineering Shari L. Pfleeger Joanne M. Atlee 4 th Edition Contents 1.1 What is Software Engineering? 1.2 How Successful Have We Been? 1.3 What Is Good Software? 1.4 Who Does
More informationWaterfall model is the earliest SDLC approach that was used for software development.
1 Waterfall Model Guide These days there is a strong push for Agile Management, as opposed to Waterfall. Personally at Castellan Systems we believe that the agility should be applied to the project development
More information