II-IT IV-SEM. 1. Software product and process. Software Engineering and Quality Assurance. Objectives:

Transcription

1 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 about software engineering. To introduce software process models. To describe a number of different process models and when they may be used. To provide an overview about business process and product engineering. Topics Covered: Introduction What Is Software Engineering? What Is A Software Process Model? Evolution Of Software Engineering Paradigms Verification And Validation Software Process Models System Engineering Computer-Based Systems Business Process Engineering: An Overview Product Engineering: An Overview

2 Introduction Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. Software engineering is a layered technology. Any engineering approach (including software engineering) must rest on an organizational commitment to quality. Software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework for a set of key process areas (KPAs) that must be established for effective delivery of software engineering technology. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established. CASE combines software, hardware, and a software engineering database (a repository containing important information about analysis, design, program construction, and testing) to create a software engineering environment analogous to CAD/CAE (computeraided design/engineering) for hardware. You Tube Video Links : Introduction to Software Engineering Lecture1 : Introduction to Software Engineering Lecture 2... What is software? Software is not just the programs but also all associated documentation and configuration data that is needed to make these programs operate correctly. A software system usually consists of a number of separate programs, configuration files, which are used to set up these programs, system documentation which describes the structure of the system, and user documentation, which explains how to use the system and web sites for users to download recent product information. There are two fundamental types of software product: 2 Software Product And Process

3 1. Generic products: These are stand-alone systems that are produced by a development organization and sold on the open market to any customer who us able to buy them. Ex: word processors etc. 2. Customized (or bespoke) products: These are systems which are commissioned by a particular customer. A software contractor develops the software especially for that customer. Ex: air traffic control systems etc. An important difference between these types of software is that, in generic products, the organization that develops the software controls the software specification. For custom products, the specification is usually developed and controlled by the organization that is buying the software. The software developers must work to that specification. What are the attributes of good software? The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. Maintainability Dependability Efficiency Usability What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use. In this definition, there are two key phases: 1. Engineering Discipline: Engineers make things work. They apply theories, methods and tools where these are appropriate, but they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods. Engineers also recognize that they must work to organizational and financial constraints, so they look for solutions with these constraints. 3 Software Product And Process

4 2. All aspects of software production: Software engineering is not just concerned with the technical processes of software development but also with activities such as software project management and with the development of tools, methods and theories to support software production. In general, software engineers adopt a systematic and organized approach to their work, as this is often the most effective way to produce high-quality software. What s the difference between software engineering and computer science? Computer science is concerned with the theories and methods that underlie computer and software systems, whereas software engineering is concerned with the practical problems of producing software. Some knowledge of computer science is essential for software engineers. Ideally, all of software engineering should be underpinned by theories of computer science, by in reality this is not the case. Software engineers must often use ad hoc approaches to developing the software. Theories of computer science cannot always be applied to real, complex problems that require a software solution. What is the difference between software engineering and system engineering? System engineering is concerned with all aspects of the development and evolution of complex systems where software plays a major role. System engineering is therefore concerned with hardware development, policy and process design and system deployment as well as software engineering. System engineers are involved in specifying the system, defining its overall architecture and then integrating the different parts to create the finished system. They are less concerned with the engineering of the system components. 4 Software Product And Process

5 What is a software process? A software process is the set of activities and associated results that produce a software product. There are four fundamental process activities that are common to all software processes. These are: 1. Software specification where customers and engineers define the software to be produced and the constraints on it operation. 2. Software development where the software is designed and programmed. 3. Software validation where the software is checked to ensure that it is what the customer requires. 4. Software evolution where the software is modified to adapt it to changing customer and market requirements. Use of an inappropriate software process may reduce the quality or usefulness of the software product to be developed and/or increase the development costs. What is a software process model? A software process model is a simplified description of a software process that presents one view of that process. Process models may include activities that are part of the software process, software products and the roles of people involved in software engineering. Some examples of the types of software process model that may be produced are: 1. A workflow model: This shows the sequence of activities in the process along with their inputs, outputs and dependencies. 2. A dataflow or activity model: This represents the process as a set of activities, each of which carries out some data transformation. It shows how the input to the process, such a specification, is transformed to an output, such as a design. 3. A role/action model: This represents the roles of the people involved in the software process and the activities for which they are responsible. 5 Software Product And Process

6 Most software process models are based on one of three general models or paradigms of software development: 1. The waterfall approach: This takes the above activities and represents them as separate process phases such as requirements specification, software design, implementation, testing and so one. After each stage is defined it is signedoff, and development goes on to the following stage. 2. Iterative development: This approach interleaves the activities of specification, development and validation. An initial system is rapidly developed from very abstract specification. This is then refined with customer input to produce a system that satisfies the customer s needs. The system may then be delivered. 3. Component-based software engineering (CBSE): This technique assumes that parts of the system already exist. The system development process focuses on integrating these parts rather than developing them from scratch. You tube Video Links: Overview of phases in Software Engineering 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 that ensure that the software that has been built is traceable to customer requirements. Boehm states this way: 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). Verification and validation encompasses a wide array of SQA activities that include formal technical reviews, quality and configuration audits, performance monitoring, simulation, feasibility study, documentation review, database review, algorithm analysis, development testing, qualification testing, and installation testing. Although testing plays an extremely important role in V&V, many other activities are also necessary. Testing does provide the last bastion from which quality can be 6 Software Product And Process

7 assessed and, more pragmatically, errors can be uncovered. But testing should not be viewed as a safety net. As they say, "You can't test in quality. If it's not there before you begin testing, it won't be there when you're finished testing." Quality is incorporated into software throughout the process of software engineering. Proper application of methods and tools, effective formal technical reviews, and solid management and measurement all lead to quality that is confirmed during testing. Miller relates software testing to quality assurance by stating that "the underlying motivation of program testing is to affirm software quality with methods that can be economically and effectively applied to both large-scale and small-scale systems." Need of Software models and Software methodologies: You tube Video: Click to View SOFTWARE PROCESS MODELS Objectives: At the end of this lesson the student will be able to: Explain what a life cycle model is. Explain what problems would occur if no life cycle model is followed. Identify the different software life cycle models. Identify the different phases of the classical waterfall model. Identify the activities undertaken in each phase. Identify the shortcomings of the classical waterfall model. Identify the phase-entry and phase-exit criteria of each phase. 7 Software Product And Process

8 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, 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. Waterfall model 8 Software Product And Process

9 Waterfall model phases 1. Requirements analysis and definition 2. System and software design 3. Implementation and unit testing 4. Integration and system testing 5. Operation and maintenance 6. The drawback of the waterfall model is the difficulty of accommodating change after the process is underway Waterfall model problems 1. Inflexible partitioning of the project into distinct stages 2. This makes it difficult to respond to changing customer requirements 3. Therefore, this model is only appropriate when the requirements are well-understood. You tube Videos: Waterfall model The Incremental Model The incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping. 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 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. 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 9 Software Product And Process

10 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. 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. 10 Software Product And Process

11 The 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. Spiral model contains six task regions: Customer communication tasks required to establish effective communication between developer and customer. Planning tasks required to define resources, timelines, and other projectrelated 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). 11 Software Product And Process

12 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. Each of the regions is populated by a set of work tasks, called a task set, that are adapted to the characteristics of the project to be undertaken. For small projects, the number of work tasks and their formality is low. For larger, more critical projects, each task region contains more work tasks that are defined to achieve a higher level of formality. In all cases, the umbrella activities (e.g., software configuration management and software quality assurance) are applied. 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. Unlike classical process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer software. An alternative view of 12 Software Product And Process

13 the spiral model can be considered by examining the project entry point axis. Each cube placed along the axis can be used to represent the starting point for different types of projects. A concept development project start at the core of the spiral and will continue (multiple iterations occur along the spiral path that bounds the central shaded region) until concept development is complete. If the concept is to be developed into an actual product, the process proceeds through the next cube (new product development project entry point) and a new development project is initiated. The new product will evolve through a number of iterations around the spiral, following the path that bounds the region that has somewhat lighter shading than the core. In essence, the spiral, when characterized in this way, remains operative until the software is retired. There are times when the process is dormant, but whenever a change is initiated, the process starts at the appropriate entry point (e.g., product enhancement). 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 is not a panacea. It 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. You tube Videos: Spiral Model in Software Engineering 13 Software Product And Process

14 The WINWIN Spiral Model The spiral model suggests a framework activity that addresses customer communication. The objective of this activity is to elicit project requirements from the customer. In an ideal context, the developer simply asks the customer what is required and the customer provides sufficient detail to proceed. Unfortunately, this rarely happens. In reality, the customer and the developer enter into a process of negotiation, where the customer may be asked to balance functionality, performance, and other product or system characteristics against cost and time to market. The best negotiations strive for a win-win result. That is, the customer wins by getting the system or product that satisfies the majority of the customer s needs and the developer wins by working to realistic and achievable budgets and deadlines. Boehm s WINWIN spiral 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: 1. Identification of the system or subsystem s key stakeholders. 2. Determination of the stakeholders win conditions. 14 Software Product And Process

15 3. Negotiation of the stakeholders win conditions to reconcile them into a set of win-win conditions for all concerned (including the software project team). Successful completion of these initial steps achieves a win-win result, which becomes the key criterion for proceeding to software and system definition. The WINWIN spiral model is illustrated in the above Figure. In addition to the emphasis placed on early negotiation, the WINWIN spiral model introduces three process milestones, called anchor points that help establish the completion of one cycle around the spiral and provide decision milestones before the software project proceeds. In essence, the anchor points represent three different views of progress as the project traverses the spiral. The first anchor point, life cycle objectives (LCO), defines a set of objectives for each major software engineering activity. For example, as part of LCO, a set of objectives establishes the definition of top-level system/product requirements. The second anchor point, life cycle architecture (LCA), establishes objectives that must be met as the system and software architecture is defined. For example, as part of LCA, the software project team must demonstrate that it has evaluated the applicability of off-the-shelf and reusable software components and considered their impact on architectural decisions. Initial operational capability (IOC) is the third anchor point and represents a set of objectives associated with the preparation of the software for installation/distribution, site preparation prior to installation, and assistance required by all parties that will use or support the software. The Concurrent Development Model The concurrent development model, sometimes called concurrent engineering, has been described in the following manner by Davis and Sitaram: Project managers who track project status in terms of the major phases [of the classic life cycle] have no idea of the status of their projects. These are examples of trying to track extremely complex sets of activities using overly simple models. Note that although... [a large] project is in the coding phase, there are personnel on the project involved in activities typically associated with many phases of development simultaneously. Most software development process models are driven by time; the later it is, the later in the development process you are. [A concurrent process 15 Software Product And Process

16 model] is driven by user needs, management decisions, and review results. The concurrent process model can be represented schematically as a series of major technical activities, tasks, and their associated states. For example, the engineering activity defined for the spiral model is accomplished by invoking the following tasks: prototyping and/or analysis modeling, requirements specification, and design..the below figure provides a schematic representation of one activity with the concurrent process model. The activity analysis may be in any one of the states10 noted at any given time. Similarly, other activities (e.g., design or customer communication) can be represented in an 16 Software Product And Process

17 All activities exist concurrently but reside in different states. For example, early in a project the customer communication activity (not shown in the figure) has completed its first iteration and exists in the awaiting changes state. The analysis activity (which existed in the none state while initial customer communication was completed) now makes a transition into the under development state. If, however, the customer indicates that changes in requirements must be made, the analysis activity moves from the under development state into the awaiting changes state. The concurrent process model defines a series of events that will trigger transitions from state to state for each of the software engineering activities. For example,during early stages of design, an inconsistency in the analysis model is uncovered. This generates the event analysis model correction which will trigger the analysis activity from the done state into the awaiting changes state. The concurrent process model is often used as the paradigm for the development of client/server11 applications. A client/server system is composed of a set of functional components. When applied to client/server, the concurrent process model defines activities in two dimensions: a system dimension and a component dimension. System level issues are addressed using three activities: design, assembly, and use. The component dimension is addressed with two activities: design and realization. Concurrency is achieved in two ways: (1) System and component activities occur simultaneously and can be modeled using the state-oriented approach described previously; (2) A typical client/server application is implemented with many components, each of which can be designed and realized concurrently. In reality, the concurrent process model is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software engineering activities to a sequence of events, it defines a network of activities. Each activity on the network exists simultaneously with other activities. Events generated within a given activity or at some other place in the activity network trigger transitions among the states of an activity. LINK: FURTHER READINGS AND INFORMATION SOURCE 17 Software Product And Process

18 COMPUTER-BASED SYSTEMS The word tells us little. We use the adjective describing system to understand the context in which the word is used. Webster's Dictionary defines system in the following way: 1. A set or arrangement of things so related as to form a unity or organic whole; 2. a set of facts, principles, rules, etc., classified and arranged in an orderly form so as to show a logical plan linking the various parts; 3. A method or plan of classification or arrangement; 4. An established way of doing something; method; procedure... Borrowing from Webster's definition, we define a computer-based system as 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. To accomplish the goal, a computer-based system makes use of a variety of system elements: Software. Computer programs, data structures, and related documentation that serve to affect the logical method, procedure, or control that is required. Hardware. Electronic devices that provide computing capability, the interconnectivity devices (e.g., network switches, telecommunications devices) that enable the flow of data, and electromechanical devices (e.g., sensors, motors, pumps) that provide external world function. People. Users and operators of hardware and software. Database. A large, organized collection of information that is accessed via software. Documentation. Descriptive information (e.g., hardcopy manuals, on-line help files, Web sites) that portrays the use and/or 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. The elements combine in a variety of ways to transform information. For example, a marketing department transforms raw sales data into a profile of the typical purchaser of a product; a robot transforms a command file containing specific instructions into a set of control signals that cause some specific physical action. Creating an information system to assist the marketing department and control software to support the robot both require system engineering. 18 Software Product And Process

19 One complicating characteristic of computer-based systems is that the elements constituting one system may also represent one macro element of a still larger system. The macro element is a computer-based system that is one part of a larger computerbased system. To summarize, the manufacturing cell and its macro elements each are composed of system elements with the generic labels: software, hardware, people, database, procedures, and documentation. In some cases, macro elements may share a generic element. For example, the robot and the NC machine both might be managed by a single operator (the people element). In other cases, generic elements are exclusive to one system. 19 Software Product And Process

20 SYSTEM ENGINEERING The system engineering process is called business process engineering when the context of the engineering work focuses on a business enterprise. When a product (in this context, a product includes everything from a wireless telephone to an air traffic control system) is to be built, the process is called product engineering. Both business process engineering and product engineering attempt to bring order to the development of computer-based systems. BUSINESS PROCESS ENGINEERING: AN OVERVIEW Introduction: The goal of business process engineering (BPE) is to define architectures that will enable a business to use information effectively. Today, each IT organization must become, in effect, its own systems integrator and architect. It must design, implement, and support its own unique configuration of heterogeneous computing resources, distributed logically and geographically throughout the enterprise, and connected by an appropriate enterprisewide networking scheme. Moreover, this configuration can be expected to change continuously, but unevenly, across the enterprise, due to changes in business requirements and in computing technology. These diverse and incremental changes must be coordinated across a distributed environment consisting of hardware and software supplied by dozens, if not hundreds, of vendors. Description: We expect these changes to be seamlessly incorporated without disrupting normal operations and to scale gracefully as those operations expand. Three different architectures must be analyzed and designed within the context of business objectives and goals: Data architecture Applications architecture Technology infrastructure 20 Software Product And Process

21 The data architecture provides a framework for the information needs of a business or business function. The individual building blocks of the architecture are the data objects that are used by the business. A data object contains a set of attributes that define some aspect, quality, characteristic, or descriptor of the data that are being described. For example, an information engineer might define the data object customer. Once a set of data objects is defined, their relationships are identified. A relationship indicates how objects are connected to one another. Not only is the specification of the appropriate computing architecture required, but the software architecture that populates the unique configuration of heterogeneous computing resources must be developed. Business process engineering is one approach for creating an overall plan for implementing the computing architecture. The application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose. In the context of this book, we consider the application architecture to be the system of programs (software) that performs this transformation. However, in a broader context, the application architecture might incorporate the role of people (who are information transformers and users) and business procedures that have not been automated. The technology infrastructure provides the foundation for the data and application architectures. The infrastructure encompasses the hardware and software that are used to support the application and data. This includes computers, operating systems, networks, telecommunication links, storage technologies, and the architecture (e.g., client/server) that has been designed to implement these technologies. To model the system architectures described earlier, a hierarchy of business process engineering activities is defined. The world view is achieved through information strategy planning (ISP). ISP views the entire business as an entity and isolates the domains of the business (e.g., engineering, manufacturing, marketing, finance, sales) that are important to the overall enterprise. ISP defines the data objects that are visible at the enterprise level, their relationships, and how they flow between the business domains.the domain view is addressed with a BPE activity called business area analysis (BAA). It is only concerned with specifying what is required in a business area. As the system engineer begins BAA, the focus narrows to a specific business domain. BAA views the business area as an 21 Software Product And Process

22 entity and isolates the business functions and procedures that enable the business area to meet its objectives and goals. BAA, like ISP, defines data objects, their relationships, and how data flow. But at this level, these characteristics are all bounded by the business area being analyzed. The outcome of BAA is to isolate areas of opportunity in which information systems may support the business area. Once an information system has been isolated for further development, BPE makes a transition into software engineering. By invoking a business system design (BSD) step, the basic requirements of a specific information system are modeled and these requirements are translated into data architecture, applications architecture, and technology infrastructure. The final BPE step construction and integration focuses on implementation detail. The architecture and infrastructure are implemented by constructing an appropriate database and internal data structures, by building applications using software components, and by selecting appropriate elements of a technology infrastructure to support the design created during BSD. Each of these system components must then be integrated to form a 22 Software Product And Process

23 complete information system or application. The integration activity also places the new information system into the business area context, performing all user training and logistics support to achieve a smooth transition. PRODUCT ENGINEERING: AN OVERVIEW The goal of product engineering is to translate the customer s desire for a set of defined Capabilities into a working product. To achieve this goal, product engineering likes business process engineering must derive architecture and infrastructure. The architecture encompasses four distinct system components: software, hardware, data (and databases), and people. A support infrastructure is established and includes the technology required to tie the components together and the information (e.g., documents, CD-ROM, video) that is used to support the components. Referring to Figure 10.3, the world view is achieved through requirements engineering. The overall requirements of 23 Software Product And Process

24 the product are elicited from the customer. These requirements encompass information and control needs, product function and behavior, overall product performance, design and interfacing constraints, and other special needs. Once these requirements are known, the job of requirements engineering is to allocate function and behavior to each of the four components noted earlier. Once allocation has occurred, system component engineering commences. System component engineering is actually a set of concurrent activities that address each of the system components separately: software engineering, hardware engineering, human engineering, and database engineering. Each of these engineering disciplines takes a domain-specific view, but it is important to note that the engineering disciplines must establish and maintain active communication with one another. Part of the role of requirements engineering is to establish the interfacing mechanisms that will enable this to happen. The element view for product engineering is the engineering discipline itself applied to the allocated component. For software engineering, this means analysis and design modeling activities (covered in detail in later chapters) and construction and integration activities that encompass code generation, testing, and support steps. The analysis step models allocated requirements into representations of data, function, and behavior. Design maps the analysis model into data, architectural, interface, and software component-level designs. SUMMARY A high-technology system encompasses a number of elements: software, hardware, people, database, documentation, and procedures. System engineering helps to translate a customer s needs into a model of a system that makes use of one or more of these elements. System engineering begins by taking a world view. A business domain or product is analyzed to establish all basic business requirements. Focus is then narrowed to a domain view, where each of the system elements is analyzed individually. Each element is allocated to one or more engineering components, which are then addressed by the relevant engineering discipline. 24 Software Product And Process

25 Self assessment: 1. How does a phased life cycle model assist software management? 2. What are two required characteristics of a milestone? 3. For each of the following documents, indicate in which phase(s) of the software life cycle it is produced: final user manual, architectural design, SQA plan, module specification, source code, statement of work, test plan, preliminary user manual, detailed design, cost estimate, project plan, test report, documentation. 4. Order the following tasks in terms of the waterfall model: acceptance testing, project planning, unit testing, requirements review, cost estimating, high-level design, market analysis, low-leveldesign, systems testing, design review, implementation. 5. Draw a diagram that represents an iterative life cycle model. Answers to assessment Questions: 1. How does a phased life cycle model assist software management? The phased life cycle improves the visibility of the project. The project can be managed by using the phases as milestones. More detailed phases will allow closer monitoring of progress. 2. What are the two required characteristics of a milestone? A milestone (1) must be related to progress in the software development and (2) must be obvious when it has been accomplished. 3. Documents in the software life cycle: Final user manual Implementation phase Architectural design Design phase SQA plan Project planning phase Module specification Design phase Source code Implementation phase Statement of work Feasibility phase 25 Software Product And Process

26 Test plan Requirements phase Preliminary user manual Requirements phase Detailed design Design phase Cost estimate Project planning phase Project plan Project planning phase Test report Testing phase Documentation Implementation phase 4. Order of tasks: Market analysis Project planning, cost estimating, requirement specification (may be done concurrently) Requirements review High-level design Low-level design Design review Implementation Unit testing Systems testing Acceptance testing 5. Draw a diagram that represents an iterative life cycle model. 26 Software Product And Process

27 Objective type questions: 1. In a classical waterfall model, which phase precedes the design phase? Coding and unit testing Maintenance Requirements analysis and specification Feasibility study 2. Among development phases of software life cycle, which phase typically, consumes the maximum effort? Requirements analysis and specification Design Coding Testing 3. Among all the phases of software life cycle, which phase consumes the maximum effort? Design Maintenance Testing Coding 4. In the classical waterfall model during which phase is the Software Requirement Specification (SRS) document produced? Design Maintenance Requirements analysis and specification Coding 5. Which phase is the last development phase of a classical waterfall software life cycle? Design Maintenance Testing Coding 6. Which development phase in classical waterfall life cycle immediately follows coding phase? Design Maintenance Testing Requirement analysis and specification 27 Software Product And Process

28 7. Out of the following life cycle models which one can be considered as the most general model, and the others as specialization of it? Classical Waterfall Model Iterative Waterfall Model Prototyping Model Spiral Model Mark the following as either True or False. Justify your answer. 1. Evolutionary life cycle model is ideally suited for development of very small software products typically requiring a few months of development effort. Ans.: - False. Explanation: - The Evolutionary model is very useful for very large problems where it becomes easier to find modules for incremental implementation. 2. Prototyping life cycle model is the most suitable one for undertaking a software development project susceptible to schedule slippage. Ans.: - False. Explanation: - The prototype model is suitable for projects whose user requirements or the underlying technical aspects are not well understood. 3. Spiral life cycle model is not suitable for products that are vulnerable to large number of risks. Ans.: - False. Explanation: - The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. Possible Questions: 1. Explain how both the waterfall model and the prototyping model can be accommodated in the spiral process model. 2. Mention the six specific design process activities. Give explanation for two of them. 3. Software is product. Justify this statement. 4. Explain the attributes of good software. 5. Explain the salient features of spiral model of a software process with an illustration diagram. 6. Explain different the different stages of testing a process with a neat diagram. 7. What is software validation? Explain with an example. 8. Describe the professional responsibilities of a software engineer. 28 Software Product And Process