Software Engineering: A Practitioner's Approach 7e PDF

Text Books 1 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.  What is Software? The product that software professionals bui...

Text Books 1 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.  What is Software? The product that software professionals build and then support over the long term. Software encompasses: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately store and manipulate information and (3) documentation that describes the operation and use of the programs. 2 Software products Generic products Stand-alone systems that are marketed and sold to any customer who wishes to buy them. Examples – PC software such as editing, graphics programs, project management tools; CAD software; software for specific markets such as appointments systems for dentists. Customized products Software that is commissioned by a specific customer to meet their own needs. Examples – embedded control systems, air traffic control software, traffic monitoring systems. 3  Dual Role of Software  Software takes a dual role.  Both a product and a vehicle for delivering a product  Product  Delivers computing potential(network of computers are accessible by a computer)  Whether it resides within a cellular phone or inside a computer, it is an information transformer --Produces, manages, acquires, modifies, display, or transmits information  Vehicle  Supports or directly provides system functionality  Controls other programs (e.g., operating systems)  Effects communications (e.g., networking software)  Helps build other software (e.g., software tools) 4  Why Software is Important? The economies of ALL developed nations are dependent on software. More and more systems are software controlled ( transportation, medical, telecommunications, military, industrial, entertainment,) Software engineering is concerned with theories, methods and tools for professional software development. Expenditure on software represents a significant fraction of GNP in all developed countries.  Characteristics of Software  Its characteristics that make it different from other things human being build. Features of such logical system: Software is developed or engineered, it is not manufactured in the classical sense. Both activities are dependent on people , but the relationship between people applied and work accomplished is entirely different. 6 2. Software doesn't "wear out.” ü Hardware has bathtub curve of failure rate ( high failure rate in the beginning, then drop to steady state, then cumulative effects of dust, vibration, abuse occurs). Software deteriorates (due to change). ü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 machine executable code. 7 Hardware Failure Curve 8 Software Failure Curve 9 3. Although the industry is moving toward component- based construction, most software continues to be custom built (it is still complex to build) Ex: component-based construction (e.g. standard screws and off-the-shelf integrated circuits), Modern reusable components encapsulate data and processing into software parts to be reused by different programs. E.g. graphical user interface, window, pull-down menus in library etc. 10  Changing Nature of Software / Software Applications 1. System software 2. Application software 3. Engineering/scientific software 4. Embedded software 5. Product-line software 6. WebApps 7. AI 8.Open world computing 9.Netsourcing 10.Open source 11  System software: A collection of programs written to service other programs Ex: compilers, editors, file management utilities, OS components, drivers etc.  Application software: Stand-alone programs for specific needs. Ex: Office software suites might include word processing, spreadsheet, database, presentation, and email applications.  Engineering/scientific software: Characterized by “number crunching”algorithms, Ex: astronomy to volcano logy, automotive stress analysis, to space shuttle orbital dynamics , molecular biology to automated manufacturing etc 12  Embedded software: resides within a product or system. And is used to implement and control features and functions for the end user and for the system itself.  Ex: key pad control of a microwave oven, digital function of dashboard display in a car  Product-line software : It provides a specific capability for use by many different customers. (focus on a limited marketplace to address mass consumer market.)  Ex: word processing, graphics, database management, inventory control,multimedia 13  Web applications: These will provide standalone features ,computing functions to the end user along with remote database and business applications. Ex: linked hypertextfiles that present information using text and limited graphics.  Artificial intelligence software: software uses non-numerical algorithm to solve complex problem. Ex: Robotics, expert system, pattern recognition ,game playing 14 Software-New Categories Ubiquitous computing: How to allow mobile devices, personal computer, enterprise system to communicate across vast network. Netsourcing (net-wide computing):Web as Computing Engine and Content Provider. Open source: ”free” source code open to the computing community. (operating systems, databases, development environments) 15 Legacy Software Definition : Legacy software systems were developed decades ago and have been continually modified to meet changes in business requirements and computing platforms. The proliferation of such systems is causing head aches for large organizations who find them costly to maintain and risky to evolve. 16  Support core business functions Have longevity and business criticality Exhibit poor quality Convoluted code, poor documentation, poor testing, poor change management Characteristics 17  (Adaptive) Must be adapted to meet the needs of new computing environments or technology. (Pe rfe c tive ) Must be e nha nc e d to imple me n t n e w b u s i n e s s requirements (Corrective) Must be re-architected to make it viable within a network environment. (Interoperable)The software must be extended to make it interoperable with more modern systems or databases Reasons for Evolving the Legacy Software 18  Software Myths Erroneous beliefs about software and the process that is used to build it. Affect managers, customers (and other non-technical stakeholders) and practitioners Are believable because they often have elements of truth, but … Invariably lead to bad decisions, therefore … Insist on reality as you navigate your way through software engineering 19 20  Software Myths - Management  Myth:"We already have a book that is full of standards and procedures for building software. Won't that provide my people with everything they need to know?“  Reality: Not used, not up-to-date, not complete, not focused on quality, time, and money  Myth:"If we get behind, we can add more programmers and catch up"  Reality: “Adding people to a late software project makes it later”  Training time reduces the amount of time spent on productivity development.  Myth:" "If I decide to outsource the software project to a third party, I can just relax and let that firm build it"  Reality:Software projects need to be controlled and managed 21 22 Software Myths - Customer Myth:"A general statement of objectives is sufficient to begin writing programs – we can fill in the details later" Reality :Ambiguous statement of objectives is a recipe for disaster Unambiguous requirements are developed only through effective and continuous communication between customer and developer. "Project requirements continually change, but change can be easily accommodated because software is flexible" Impact of change depends on where and when it occurs in the software life cycle (requirements analysis, design, code, test) 23 24 Adding extra features at any point isn’t a big deal 25  "Once we write the program and get it to work, our job is Software done" Myths - Practitioner  60% to 80% of all effort expended on software occurs after it is delivered  "Until I get the program running, I have no way of assessing its quality  Formal technical reviews of requirements analysis documents, design documents, and source code (more effective than actual testing)  "The only deliverable work product for a successful project is the working program"  Software, documentation, test drivers, test results  "Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down"  Creates quality, not documents; quality reduces rework and26 provides software on time and within the budget   https://www.youtube.com/watch?v=OFBK-I0rrNk 27 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Software Engineering Definition The seminal definition: [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. The IEEE definition: 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). Importance of Software Engineering More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly. It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of system, the majority of costs are the costs of changing the software after it has gone into use. 29 Software Engineering A Layered Technology n Any engineering approach must rest on organizational commitment to quality which fosters a continuous process improvement culture. n Process layer as the foundation defines a framework with activities for effective delivery of software engineering technology. Establish the context where products (model, data, report, and forms) are produced, milestone are established, quality is ensured and change is managed. n Method provides technical how-to’s for building software. It encompasses many tasks including communication, requirement analysis, design modeling, program construction, testing and support. 30 n Tools provide automated or semi-automated support for the process and methods.  A process is a collection of activities, actions and tasks that are performed when some work product is to be created. It is not a rigid prescription for how to build computer software. Rather, it is an adaptable approach that enables the people doing the work to pick and choose the appropriate set of work actions and tasks. Purpose of process is to deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it. Software Process 31  Umbrella Activities Complement the five process framework activities and help team manage and control progress, quality, change, and risk. Software project tracking and control: assess progress against the plan and take actions to maintain the schedule. Risk management: assesses risks that may affect the outcome and quality. Software quality assurance: defines and conduct activities to ensure quality. Technical reviews: assesses work products to uncover and remove errors before going to the next activity. Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs are met. Software configuration management: manage the effects of change throughout the software process. Reusability management: defines criteria for work product reuse and establishes mechanism to achieve reusable components. Work product preparation and production: create work products such32 as models, documents, logs, forms and lists.  Definition of Software Process A framework for the activities, actions, and tasks that are required to build high-quality software. SP defines the approach that is taken as software is engineered. Is not equal to software engineering, which also encompasses technologies that populate the process– technical methods and automated tools. 33 A Generic Process Model 34 n A generic process framework for software engineering defines five framework activities-communication, planning, modeling, construction, and deployment. n In addition, a set of umbrella activities- project tracking and control, risk management, quality assurance, configuration management, technical reviews, and others are applied throughout the process. A Generic Process Model 35 Process Flow 36 n Before you can proceed with the process model, a key question: what actions are appropriate for a framework activity given the nature of the problem, the characteristics of the people and the stakeholders? n A task set defines the actual work to be done to accomplish the objectives of a software engineering action. n A list of the task to be accomplished n A list of the work products to be produced n A list of the quality assurance filters to be applied Identifying a Task Set 37 n For example, a small software project requested by one person with simple requirements, the communication activity might encompass little more than a phone all with the stakeholder. Therefore, the only necessary action is phone conversation, the work tasks of this action are: n 1. Make contact with stakeholder via telephone. n 2. Discuss requirements and take notes. n 3. Organize notes into a brief written statement of requirements. n 4. E-mail to stakeholder for review and approval. Identifying a Task Set 38 n The task sets for Requirements gathering action for a simple project may include: Make a list of stakeholders for the project. Invite all stakeholders to an informal meeting. Ask each stakeholder to make a list of features and functions required. Discuss requirements and build a final list. Prioritize requirements. Note areas of uncertainty. Example of a Task Set for Elicitation 39 n The task sets for Requirements gathering action for a big project may include: Make a list of stakeholders for the project. Interview each stakeholders separately to determine overall wants and needs. Build a preliminary list of functions and features based on stakeholder input. Schedule a series of facilitated application specification meetings. Conduct meetings. Produce informal user scenarios as part of each meeting. Refine user scenarios based on stakeholder feedback. Build a revised list of stakeholder requirements. Use quality function deployment techniques to prioritize requirements. Package requirements so that they can be delivered incrementally. Note constraints and restrictions that will be placed on the system. Discuss methods for validating the system.  Both do the same work with different depth and formality. Choose the task sets that achieve the goal and still maintain quality and agility. 40 Example of a Task Set for Elicitation  A process pattern describes a process-related problem that is encountered during software engineering work, identifies the en v i r o n m e n t i n w h i c h t h e pr o b l e m h a s b e e n encountered, and suggests one or more proven solutions to the problem. Stated in more general terms, a process pattern provides you with a template [Amb98]—a consistent method for describing problem solutions within the context of the software process. ( defined at different levels of abstraction) Problems and solutions associated with a complete process model (e.g. prototyping). Problems and solutions associated with a framework activity (e.g. planning) or 1. an action with a framework activity (e.g. project estimating). Process Patterns 41  Stage patterns—defines a problem associated with a framework activity for the process. It includes multiple task patterns as well. For example, EstablishingCommunication would incorporate the task pattern RequirementsGathering and others. Task patterns—defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of a c t i v i t i e s i s i t e r a t i ve i n n a t u r e. E x a m p l e i n c l u d e s SprialModel or Prototyping. 42 Process Pattern Types  An Example of Process Pattern Describes an approach that may be applicable when stakeholders have a general idea of what must be done but are unsure of specific software requirements. Pattern name. RequiremetnsUnclear Intent. This pattern describes an approach for building a model that can be assessed iteratively by stakeholders in an effort to identify or solidify software requirements. Type. Phase pattern Initial context. Conditions must be met (1) stakeholders have been identified; (2) a mode of communication between stakeholders and the software team has been established; (3) the overriding software problem to be solved has been identified by stakeholders ; (4) an initial understanding of project scope, basic business requirements and project constraints has been developed. Problem. Requirements are hazy or nonexistent. stakeholders are unsure of what they want. Solution. A description of the prototyping process would be presented here. Resulting context. A software prototype that identifies basic requirements. (modes of interaction, computational features, processing functions) is approved by stakeholders. Following this, 1. This prototype may evolve through a series of increments to become the production software or 2. the prototype may be discarded. Related patterns. CustomerCommunication, IterativeDesign, IterativeDevelopment, CustomerAssessment, RequirementExtraction. 43  Process Assessment and Improvement SP cannot guarantee that software will be delivered on time, meet the needs, or has the desired technical characteristics. However, the process can be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting and learning. CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment [Dun01] SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined software process. [ISO08] ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides. Therefore, the standard is directly applicable to software organizations and companies. [Ant06] 44 Assessment and Improvement Software Process identifies is examined by identifies capabilities modifications to and risk of Software Process Assessment Capability Software Process leads to leads to Determination Improvement motivates 45  Personal Software Process (PSP) Recommends five framework activities: Planning High-level design High-level design review Development Postmortem Stresses the need for each software engineer to identify errors early and as important, to understand the types of errors 46 Team Software Process (TSP) Each project is “launched” using a “script” that defines the tasks to be accomplished Teams (of 2 to 20 engineers) are self-directed: Plan and track work, set goals, own processes and plans Measurement is encouraged Measures are analyzed with the intent of improving the team process (through coaching, motivation, …) 47 The Primary Goal of Any Software Process: High Quality 48 Software Engineering Definition The seminal definition: [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. The IEEE definition: S o f t w a re E n g i n e e r i n g : ( 1 ) T h e a p p l i c a t i o n o f 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). Software Engineering A Layered Technology n Any engineering approach must rest on organizational commitment to quality which fosters a continuous process improvement culture. (Total Quality Management, six sigma etc) n The bedrock that supports software engineering is a quality focus. n Process layer as the foundation defines a framework with activities for effective delivery of software engineering technology. Establish the context where products (model, data, report, and forms) are produced, milestone are established, quality is ensured and change is managed. n Method provides technical how-to’s for building software. It encompasses many tasks including communication, requirement analysis, design modeling, program construction, testing and support. n Tools provide automated or semi-automated support for the process and methods. 50  A process is a collection of activities, actions and tasks that are performed when some work product is to be created. It is not a rigid prescription for how to build computer software. Rather, it is an adaptable approach that enables the people doing the work to pick and choose the appropriate set of work actions and tasks. Purpose of process is to deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it. Software Process 51  A process framework establishes the foundation for a complete software process by identifying a small number of framework activities that are applicable to all software projects regardless of their size or complexity. Process framework encompasses a set of umbrella activities that are applicable across the entire software process. Each framework activity is populated by a set of software engineering actions- a collection of related tasks that produces a major software engineering work product. Each action is populated with individual work tasks that accomplish some part of the work implied by the action. A Process Framework 52 A Generic Process Model 53 n A generic process framework for software engineering defines five framework activities- ü communication: heavy communication and collaboration with he customer and encompasses requirements gathering and other related activities ü P l a n n i n g : e s t a b l i s h e s a p l a n f o r t h e s o f t wa r e e n g i n e e r i n g work.Describes the technical tasks to be conducted, likely risks, work products to be produced and work schedule. ü Modeling: creation of models for better unders tanding the requirements and deign that will achieve those requirements. ü Construction: Combines code generation and testing ü Deployment : delivering the product to the customer and provides feedback based on evaluation. 54 Umbrella Activities Complement the five process framework activities and help team manage and control progress, quality, change, and risk. Software project tracking and control: assess progress against the plan and take actions to maintain the schedule. Risk management: assesses risks that may affect the outcome and quality. Software quality assurance: defines and conduct activities to ensure quality. Technical reviews: assesses work products to uncover and remove errors before going to the next activity. Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs are met. Software configuration management: manage the effects of change throughout the software process. Reusability management: defines criteria for work product reuse and establishes mechanism to achieve reusable components. Work product preparation and production: create work products such as models, documents, logs, forms and lists. 55 n A task set defines the actual work to be done to accomplish the objectives of a software engineering action. n A list of the task to be accomplished n A list of the work products to be produced n A list of the quality assurance filters to be applied Identifying a Task Set 56 n For example, a small software project requested by one person with simple requirements, the communication activity might encompass little more than a phone all with the stakeholder. Therefore, the only necessary action is phone conversation, the work tasks of this action are: n 1. Make contact with stakeholder via telephone. n 2. Discuss requirements and take notes. n 3. Organize notes into a brief written statement of requirements. n 4. E-mail to stakeholder for review and approval. Identifying a Task Set 57 n The task sets for Requirements gathering action for a simple project may include: Make a list of stakeholders for the project. Invite all stakeholders to an informal meeting. Ask each stakeholder to make a list of features and functions required. Discuss requirements and build a final list. Prioritize requirements. Note areas of uncertainty. Example of a Task Set for Elicitation 58 n The task sets for Requirements gathering action for a big project may include: Make a list of stakeholders for the project. Interview each stakeholders separately to determine overall wants and needs. Build a preliminary list of functions and features based on stakeholder input. Schedule a series of facilitated application specification meetings. Conduct meetings. Produce informal user scenarios as part of each meeting. Refine user scenarios based on stakeholder feedback. Build a revised list of stakeholder requirements. Use quality function deployment techniques to prioritize requirements. Package requirements so that they can be delivered incrementally. Note constraints and restrictions that will be placed on the system. Discuss methods for validating the system.  Both do the same work with different depth and formality. Choose the task sets that achieve the goal and still maintain quality and agility. 59 Example of a Task Set for Elicitation  A process pattern provides us with a template [Amb98]— a consistent method for describing an important characteristic of the software process. By combining patterns, a software team can construct a process that best meets the needs of a project Process patterns can be defined at different levels of abstraction A pattern might be used to describe a complete process model (e.g. prototyping). A pattern might be used to describe a framework activity (e.g. planning) or 1. an action with a framework activity (e.g. project estimating). Process Patterns 60  Stage patterns—defines a framework activity for the process. It includes multiple task patterns as well. Ex:Communication would incorporate the task pattern RequirementsGathering and others. Task patterns—defines a software engineering action or work task that is part of process Ex: Requirements gathering Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature. Ex: Sprial Model or Prototyping. Process Pattern Types 61  An Example of Process Pattern Pattern name: The pattern is given a meaningful name that describes its function within the software process Ex: customer-communication Intent: The objective of the pattern is described briefly Type: Task Pattern Initial context: The conditions under which the pattern applied are described Problem: The problem to be solved by the pattern is described. Solution: The implementation of pattern is described. Resulting context: The conditions that will result once the pattern has been successfully implemented are discussed. Related patterns: related patterns are listed. Ex: Requirements gathering, project-team assembly Known uses/ Examples: communication is important at the beginning of every 62 software project.  63 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.  Process Assessment and Improvement Software Process cannot guarantee that software will be delivered on time, meet the needs, or has the desired technical characteristics. However, the process can be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting and learning. CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment. SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined software process. ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides. Therefore, the standard is directly applicable to software organizations and companies. 64 Assessment and Improvement Software Process identifies is examined by identifies capabilities modifications to and risk of Software Process Assessment Capability Software Process leads to leads to Determination Improvement motivates 65  Watts Humphrey argues that it is possible to create a “personal software process” and/or a “team software process.” Both require hard work, training, and co- ordination, but both are achievable PSP & TSP These slides are designed to accompany Software Engineering: 66 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.  Personal Software Process (PSP) PSP emphasizes personal measurement of both the work product and the quality of the work product. Recommends five framework activities: Planning (size , resource & defect estimates) High-level design (prototypes are built) High-level design review (reviews to uncover errors) Development (code is generated, reviewed, compiled and tested) Postmortem (Effectiveness of process is determined) PSP stresses the need for each software engineer to identify errors early and as important, to understand the types of errors 67 Team Software Process (TSP) The goal of TSP is to build self –directed project team that organizes itself to produce high-quality software. Each project is “launched” using a “script” that defines the tasks to be accomplished Teams (of 2 to 20 engineers) are self-directed: Plan and track work, set goals, own their processes and plans Measurement is encouraged Making CMM Level 5 behavior normal and expected. Measures are analyzed with the intent of improving the team process (through coaching, motivation, …) 68  Team Software Process (TSP) Recommends five framework activities: Project Launch High-level design Implementation Integration & Test Postmortem TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team members in their work. “Scripts” define specific process activities (i.e., project launch, design, implementation, integration and system testing, postmortem) and other more detailed work functions (e.g., development planning, requirements development, software configuration management, unit test) that are part of the team process. 69 Process Models  Prescriptive Process Models Often referred to as “conventional” process models Prescribe a set of process elements – Framework activities – Software engineering actions – Tasks – Work products – Quality assurance and – Change control mechanisms for each project There are a number of prescriptive process models in operation Each process model also prescribes a workflow Various process models differ in their emphasis on different activities and workflow 71 72 73  The Waterfall Model Sometimes called the classic life cycle Suggests a systematic, sequential (or linear) approach to s/w development. The oldest paradigm for s/w engineering Works best when – – Requirements of a problem are reasonably well understood – Well-defined adaptations or enhancements to an existing system must be made – Requirements are well-defined and reasonably stable 74  The Waterfall Model Waterfall Model suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software. 75  The Waterfall Model - Problems Real projects rarely follow the sequential flow – Accommodates iteration indirectly – Changes can cause confusion as the project team proceeds It is often difficult for the customer to state all requirements explicitly – Has difficulty accommodating the natural uncertainty that exists at the beginning of many projects The customer must have patience – A working version of the program(s) will not be available until late in the project time-span – A major blunder, if undetected until the working program is reviewed, can be disastrous Leads to “blocking states” 76 Incremental Process Models The incremental model 77  Incremental Process Models Combines elements of the waterfall model applied in an iterative fashion Each linear sequence produces deliverable “increments” of the software The first increment is often a core product 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 evaluation). 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. 78  Incremental Process Models 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 79  When to use Incremental Process model ? 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. Increments can be planned to manage technical risks. 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. 80  The RAD Model Rapid Application Development Emphasizes a short development cycle A “high speed” adaptation of the waterfall model Uses a component-based construction approach May deliver software within a very short time period ( e. g. , 6 0 to 9 0 d ays ) i f re q u i re m e nt s a re we l l understood and project scope is constrained. The time constraints imposed on a RAD project demand “scalable scope”. The application should be modularized and addressed by separate RAD teams Integration is required 81  The RAD Model Team # n Modeling business modeling data modeling process modeling Construction Team # 2 component reuse Modeling automatic code Communication business modeling generation data modeling testing process modeling Planning Construction Team # 1 component reuse Deployment automatic code integration Modeling delivery business modeling generation testing feedback data modeling process modeling Construction component reuse automatic code generation testing 60 – 90 days 82  The RAD Model Business modeling: The information flow is identified between various business functions. Data modeling: Information gathered from business modeling is used to define data objects that are needed for the business. Process modeling: Data objects defined in data modeling are converted to achieve the business information flow to achieve some specific business objective. Description are identified and created for CRUD of data objects. Application generation: Automated tools are used to convert process models into code and the actual system. Testing and turnover: Test new components and all the interfaces. 83  The RAD Model - Drawbacks For large, but scalable projects, RAD requires sufficient human resources. RAD projects will fail if developers and customers are not committed to the rapid-fire activities. 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 may not be appropriate when technical risks are high 84  Evolutionary Process Models Software, like all complex systems, evolves over a period of time Business and product requirements often change as development proceeds, making a straight-line path to an end product is unrealistic. Evolutionary models are iterative 85 Prototyping 86  The prototyping paradigm begins with communication. You meet with other stakeholders to define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A prototyping iteration is planned quickly, and modeling (in the form of a “quick design”)occurs. A quick design focuses on a representation of those aspects of the software that will be visible to end users (e.g., human interface layout or output display formats). The quick design leads to the construction of a prototype. The prototype is deployed and evaluated by stakeholders, who provide feedback that is used to further refine requirements. Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the same time enabling you to better understand what needs to be done. 87  Prototyping - Problems Stakeholders see what appears to be a working version of the software, unaware that the prototype is held together haphazardly, unaware that in the rush to get it working you haven’t considered overall software quality or long-term maintainability. When informed that the product must be rebuilt so that high levels of quality can be maintained, stakeholders cry foul and demand that “a few fixes” be applied to make the prototype a working product. 2. As a software engineer, you often make implementation compromises in order to get a prototype working quickly. An inappropriate operating system or programming language may be used simply because it is available and known; an inefficient algorithm may be implemented simply to demonstrate capability. After a time, you may become comfortable with these choices and forget all the reasons why they were inappropriate. 88  The Spiral Model Couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model It provides the potential for rapid development of increasingly more complete versions of the software It is a risk-driven process model generator It has two main distinguishing features – Cyclic approach Incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk – A set of anchor point milestones A combination of work products and conditions that are attained along the path of the spiral 89 The Spiral Model 90  The Spiral Model 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 the customer after delivery. In addition, the project manager adjusts the planned number of iterations required to complete the software. 91  The Spiral Model Unlike other process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer s/w. The circuits around the spiral might represent – Concept development project – New Product development project – Product enhancement project The spiral model demands a direct consideration of technical risks at all stages of the project 92  The first circuit around the spiral might represent a “concept development project” that starts at the core of the spiral and continues for multiple iterations until concept development is complete. If the concept is to be developed into an actual product, the process proceeds outward on the spiral and a “new product development project” commences. The new product will evolve through a number of iterations around the spiral. Later, a circuit around the spiral might be used to represent a “product enhancement project.” In essence, the spiral, when characterized in this way, remains operative until the software is retired. 93  The Spiral Model - Drawbacks 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. 94  Concurrent Development Model Sometimes called concurrent engineering It allows a software team to represent iterative and concurrent elements of any of the process models Can be represented schematically as a series of framework activities, s/w engineering actions and tasks, and their associated states Concurrent modeling defines a series of events that will trigger transitions from state to state for each of the s/w engineering activities, actions, or tasks. 95  Applicable to all types of s/w development and provides an accurate picture of the current state of a project Defines a network of activities 96  Modeling activity -concurrent modeling approach For example, early in a project the communication activity has completed its first iteration and exists in the awaiting changes state. The modeling activity (which existed in the inactive state while initial 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 modeling activity moves from the under development state into the awaiting changes state. 97  For example, during early stages of design, an inconsistency in the requirements model is uncovered. This generates the event analysis model correction, which will trigger the requirements analysis action from the done state into the awaiting changes state. 98  Weaknesses of Evolutionary Process Models Uncertainty in the number of total cycles required – Most project management and estimation techniques are based on linear layouts of activities, so they do not fit completely. Do not establish the maximum speed of the evolution - Evolutions should not occur too fast or too slow. Software processes should be focused on flexibility and extensibility rather than on high quality, which sounds scary – However, we should prioritize the speed of the development over zero defects. 99  The Unified Process (UP) It is a use-case driven, architecture-centric, iterative and incremental software process UP is an attempt to draw on the best features and characteristics of conventional s/w process models Also implements many of the best principles of agile software development UP is a framework for object-oriented software engineering using UML (Unified Modeling Language) 100  The Unified Process recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system (the use case). It emphasizes the important role of software architecture and “helps the architect focus on the right goals, such as understandability, reliance to future changes, and reuse”. It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is essential in modern software development. 101 Phases of the Unified Process 102  Phases of UP - Inception Encompasses both customer communication and planning activities Fundamental business requirements are described through a set of preliminary use-cases – A use-case describes a sequence of actions that are performed by an actor (e.g., a person, a machine, another system) as the actor interacts with the software. A rough architecture for the system is also proposed. Architecture at this point is nothing more than a tentative outline of major subsystems and the function and features that populate them. Planning identifies resources, assesses major risks, defines 103 a schedule etc.  Phases of UP - Elaboration Encompasses customer communication and modeling activities Elaboration refines and expands the preliminary use-cases that were developed as part of the inception. Expands the architectural representation to include five different views of the software – The use-case model – The analysis model – The design model – The implementation model – The deployment model In some cases, elaboration creates an “executable architectural baseline” that represents a “first cut” executable system Planning is carefully reviewed at the end of this phase and modifications to the plan can be made at this time 104  Phases of UP - Construction The construction phase of the UP is identical to the construction activity defined for the generic software process. Using the architectural model as input ,the construction phase , makes each use-case operational for end-users. Requirements and design models that were started during the elaboration phase are completed to reflect the final version of the 105  Phases of UP - Transition The transition phase of the UP encompasses the latter stages of the generic construction activity and the first part of the generic deployment (delivery and feedback) activity Software is given to end-users for beta testing and user feedback reports both defects and necessary changes. The software team creates the necessary support information – – User manuals – Trouble-shooting guides – Installation procedures At the conclusion of the transition phase, the software increment becomes a usable software release 106  Phases of UP - Production Coincides with the deployment activity of the generic process The on-going use of the software is monitored Support for the operating environment (infrastructure) is provided Defect reports and requests for changes are submitted and evaluated 107 Unified Process Work Products Inception – Vision document – Initial use-case model – Initial project glossary – Initial risk assessment Elaboration – Use case model, analysis model, executable architectural prototype, preliminary design model Construction – Design model, Software Components, test plan and procedure ,test cases Transition – Delivered software, beta test reports, general user 108  Cases Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems: A system to control anti-lock braking in a car A virtual reality system to support software maintenance A university accounting system that replaces an existing system An interactive travel planning system that helps users plan journeys with the lowest environmental impact 109 Anti-lock braking system This is a safety-critical system so requires a lot of up-front analysis before implementation. It certainly needs a plan-driven approach to development with the requirements carefully analysed. A waterfall model is therefore the most appropriate approach to use, perhaps with formal transformations between the different development stages. Virtual reality system This is a system where the requirements will change and there will be an extensive user interface components. Incremental development with, perhaps, some UI prototyping is the most appropriate model. An agile process may be used. University accounting system This is a system whose requirements are fairly well-known and which will be used in an environment in conjunction with lots of other systems such as a research grant management system. Therefore, a reuse-based approach is likely to be appropriate for this. 110  Waterfall: Best if requirements are clear and unchanging. Spiral: Best if managing risks is critical and the project is large and complex. RAD: Best if speed is essential and requirements are flexible. Incremental: Best if you want to deliver core features early and expand over time. 111 Agile View of a Process 112  Topics What is Agility? Why Agility is important? Agility and the Cost of Change Principles of Agile processes Agility Principles Agile process models 113  Agile software engineering combines a philosophy and a set of development guidelines. The philosophy encourages  customer satisfaction and early incremental delivery of software;  small, highly motivated project teams;  informal methods;  minimal software engineering work products;  overall development simplicity. The development guidelines stress delivery over analysis and design , and active and continuous communication between developers and customers. 114  What is “Agility”? Effective (rapid and adaptive) response to change (team members, new technology, requirements) Effective communication in structure and attitudes among all team members, technological and business people, software engineers and managers。 Drawing the customer into the team. Eliminate “us and them” attitude. Planning in an uncertain world has its limits and plan must be flexible. Organizing a team so that it is in control of the work performed Emphasize an incremental delivery strategy as opposed to intermediate products that gets working software to the customer as rapidly as feasible. 115  What is “Agility”? An agile team is a nimble team able to appropriately respond to changes. Change is what software development is very much about. Changes in the software being built, changes to the team members, changes because of new technology, changes of all kinds that may have an impact on the product they build or the project that creates the product. An agile team recognizes that software is developed by individuals working in teams and that the skills of these people, their ability to collaborate is at the core for the success of the project. 116 Why and What Steps are“Agility” important? Why? The modern business environment is fast-paced and ever-changing. It represents a reasonable alternative to conventional software engineering for certain classes of software projects. It has been demonstrated to deliver successful systems quickly. What? May be termed as “software engineering lite” The basic activities- communication, planning, modeling, construction and deployment remain. But they morph into a minimal task set that push the team toward construction and delivery sooner. The only really important work product is an operational “software increment” that is delivered. 117 Plan-driven and agile development Roger Pressman. 118  Agility and the Cost of Change Conventional wisdom is that the cost of change increases nonlinearly as a project progresses. It is relatively easy to accommodate a change when a team is gathering requirements early in a project. If there are any changes, the costs of doing this work are minimal. But if the middle of validation testing, a stakeholder is requesting a major functional change. Then the change requires a modification to the architectural design, construction of new components, changes to other existing components, new testing and so on. Costs escalate quickly. A well-designed agile process may “flatten” the cost of change curve by coupling incremental delivery with agile practices such as continuous unit testing and pair programming. Thus team can accommodate changes late in the software project without dramatic cost and time impact. 119 Agility and the Cost of Change 120  An Agile Process Is driven by customer descriptions of what is required (scenarios). Some assumptions: – Recognizes that plans are short-lived (some requirements will persist, some will change. Customer priorities will change) – Develops software iteratively with a heavy emphasis on construction activities (design and construction are interleaved, hard to say how much design is necessary before construction. Design models are proven as they are created. ) – Analysis, design, construction and testing are not predictable. Thus has to Adapt as changes occur due to unpredictability Delivers multiple ‘software increments’, deliver an operational prototype or portion of an OS to 121 Principles of Agile processes 122  Agility Principles - I  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.  Business people and developers must work together daily throughout the project.  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face–to–face conversation. 123  Agility Principles - II  Working software is the primary measure of progress.  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  Continuous attention to technical excellence and good design enhances agility. 10. Simplicity – the art of maximizing the amount of work not done – is essential. 11. The best architectures, requirements, and designs emerge from self–organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 124  Human Factors the process molds to the needs of the people and team, not the other way around key traits must exist among the people on an agile team and the team itself: – Competence. ( talent, skills, knowledge) – Common focus. ( deliver a working software increment ) – Collaboration. ( peers and stakeholders) – Decision-making ability. ( freedom to control its own destiny) – Fuzzy problem-solving ability.(ambiguity and constant changes, today problem may not be tomorrow’s problem) – Mutual trust and respect. – Self-organization. ( themselves for the work done, process for its local environment, the work schedule) 125  Agile Process Models Extreme Programming (XP) Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) Scrum Crystal Feature Driven Development (FDD) Agile Modeling (AM)  Extreme Programming (XP) The most widely used agile process, originally proposed by Kent Beck in 2004. It uses an object-oriented approach. It encompasses a set of rules and practices that occur within the context of four framework activities: Planning Design Coding Testing. 127  Extreme Programming (XP) XP Planning – Begins with the listening, leads to creation of “user stories” that describes required output, features, and functionality. – Customer assigns a value(i.e., a priority) to each story. – Agile team assesses each story and assigns a cost (development weeks. If more than 3 weeks, customer asked to split into smaller stories) – Working together, stories are grouped for a deliverable increment next release. – A commitment (stories to be included, delivery date and other project matters) is made. Three ways: 1. Either all stories will be implemented in a few weeks, 2. high priority stories first, or 3. the riskiest stories will be implemented first. – After the first increment “project velocity”, namely number of stories implemented during the first release is used to help define subsequent delivery dates for other increments. Customers can add stories, delete existing stories, change values of an existing story, split stories as development work proceeds. 128  Extreme Programming (XP) XP Design ( occurs both before and after coding as refactoring is encouraged) – Follows the KIS principle (keep it simple) Nothing more nothing less than the story. – Encourage the use of CRC (class-responsibility-collaborator) cards in an object-oriented context. The only design work product of XP. They identify and organize the classes that are relevant to the current software increment. – For difficult design problems, suggests the creation of “spike solutions”—a design prototype for that portion is implemented and evaluated. – Encourages “refactoring”—an iterative refinement of the internal program design. Does not alter the external behavior yet improve the internal structure. Minimize chances of bugs. More efficient, easy to read. 129  XP Coding – Recommends the construction of a unit test for a story before coding commences. So implementer can focus on what must be implemented to pass the test. – Encourages “pair programming”. Two people work together at one workstation. Real time problem solving, real time review for quality assurance. Take slightly different roles. XP Testing – All unit tests are executed daily and ideally should be automated. Regression tests are conducted to test current and previous components. – “Acceptance tests” are defined by the customer and executed to assess customer visible functionality 130  Extreme Programming (XP) spike solut ions simple design prot ot ypes CRC cards user st ories values accept ance t est crit eria it erat ion plan ref act oring pair programming Release sof t ware increment unit t est project v elocit y comput ed cont inuous int egrat ion accept ance t est ing 131 132 133  A spike solution, or spike, is a technical investigation. It's a small experiment to research the answer to a problem. For example, a programmer might not know whether Java throws an exception on arithmetic overflow. A quick ten-minute spike will answer the question. public class ArithmeticOverflowSpike { public static void main(String[] args) { try { int a = Integer.MAX_VALUE + 1; System.out.println("No exception: a = " + a); } catch (Throwable e) { System.out.println("Exception: " + e); } } } No exception: a = -2147483648 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw- 134 Hill, 2009) Slides copyright 2009 by  These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw- 135 Hill, 2009) Slides copyright 2009 by  These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw- 136 Hill, 2009) Slides copyright 2009 by  Adaptive Software Development (ASD) Originally proposed by Jim Highsmith (2000) Focuses on human collaboration and team self-organization as a technique to build complex software and system. ASD — distinguishing features – Mission-driven planning – Component-based focus – Uses “time-boxing” – Explicit consideration of risks – Emphasizes collaboration for requirements gathering – Emphasizes “learning” throughout the process 137 Adaptive Software Development 138  Three Phases of ASD 1. Speculation: project is initiated and adaptive cycle planning is conducted. Adaptive cycle planning uses project initiation information- the customer’s mission statement, project constraints (e.g. delivery date), and basic requirements to define the set of release cycles (increments) that will be required for the project. B a s e d o n t h e i n fo r m at i o n o b ta i n e d at t h e completion of the first cycle, the plan is reviewed and adjusted so that planned work better fits the 139 reality.  Three Phases of ASD 2. Collaboration Collaborations between motivated people are used to multiply their talent and creative output beyond absolute number. It encompasses communication and teamwork, but it also emphasizes individualism, because individual creativity plays an important role in collaborative thinking. It is a matter of trust. People working together must trust one another to 1) criticize without animosity, 2) assist without resentments, 3) work as hard as or harder than they do. 4) have the skill set to contribute to the work at hand, 5) communicate problems or concerns in a way that leads to effective action. 140 3. Learning: As members of ASD team begin to develop the components, the emphasis is on “learning”. Highsmith argues that software developers often overestimate their own understanding of the technology, the process, and the project and that learning will help them to improve their level of real understanding. 141  ASD Teams learn in three ways: 1. focus groups: Customer/end users feed back provides whether product is satisfying the needs. 2. technical reviews: ASD teams review the software components that are developed , which improves quality and learning 3. postmortems: ASD teams becomes introspective, addressing its own performance and process. These slides are designed to 142  Scrum A software development method Originally proposed by Schwaber and Beedle in early 1990. Scrum—distinguishing features – Development work is partitioned into “packets” – Testing and documentation are on-going as the product is constructed – Work units occurs in “sprints” and is derived from a “backlog” of existing changing prioritized requirements – Changes are not introduced in sprints (short term but stable) but in backlog. – “demos” are delivered to the customer with the time-box allocated. May not contain all functionalities. So customers can evaluate and give feedbacks. 143 Scrum 144 Scrum framework activities: Requirements Analysis Design Evolution Delivery 145  Scrum emphasizes the use of a set of “software process patterns” that have proven effective for projects with tight timeliness, changing requirements, and business criticality. Backlog- a prioritized list of project requirements or features that provide business value for the customer. Items can be added to the backlog at any time. The product manager assesses the backlog and updates priorities as required. 146  Sprints- consist of work units that are required to achieve a requirement defined in the backlog that must be fit into a predefined time-box(typically 30 days) Changes are not introduced during sprint. The sprint allows team members to work in a short-term, but stable environment. 147  Scrum Meetings- Meetings are very short (15 minutes daily) and sometimes conducted without chairs i) What did you do since last meeting? ii) What obstacles are you encountering? iii) What do you plan to accomplish by next meeting? A team leader called a “scrum master” leads the meeting and assesses the responses from each person. The scrum meeting helps to uncover potential problems as early as possible. 148  Demos-deliver the software increment to the customer so that functionality that has been implemented can be demonstrated and evaluated by the customer. 149 150  Crystal Proposed by Cockburn and Highsmith Crystal—distinguishing features – Actually a family of process models that allow “maneuverability” based on problem characteristics – Face-to-face communication is emphasized – Suggests the use of “reflection workshops” to review the work habits of the team – This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project 's unique characteristics maneuverability the quality of being easy to move and direct: Maneuverability is called movement or series of moves. In the field of aeronautics it is known as Aerobatics means free movement of fighter jet. 151  Crystal is characterized as a resource limited, cooperative game of invention and communication, with a primary goal of delivering useful, working software and a secondary goal of setting up for the next game”. To achieve maneuverability, Cockburn and Highsmith have defined a set of methodologies, each with core elements that are common to all, and roles, process patterns, work products, and practice that are unique to each. The Crystal family is actually a set of example agile processes that have been proven effective for different types of projects. The intent is to allow agile teams to select the member of the crystal family that is most appropriate for their project and environment. 152  Which approach will be most suitable for your projects depends on three dimensions: Team size Criticality What the priority of the project is 153 https://activecollab.com/blog/project-management/crystal-methods These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw- 154 Hill, 2009) Slides copyright 2009 by  Feature Driven Development Originally proposed by Peter Coad et al as a object-oriented software engineering process model. FDD—distinguishing features – Emphasis is on defining “features” which can be organized hierarchically. a feature “is a client-valued function that can be implemented in two weeks or less.” – Uses a feature template – A features list is created and “plan by feature” is conducted – Design and construction merge in FDD 155 Feature Driven Development 156 FDD adopts a philosophy that emphasizes collaboration among people on an FDD team; manages problem and project complexity using feature-based decomposition followed by the integration of software increments (3) communication of technical detail using verbal, graphical, and text-based means. 157 FDD emphasizes software quality assurance activities by encouraging an incremental development strategy, the use of design and code inspections, the application of software quality assurance audits, the collection of metrics, and the use of patterns 158  Benefits of features Because features are small blocks of deliverable functionality, users can describe them more easily; understand how they relate to one another more readily; and better review them for ambiguity, error, or omissions. Features can be organized into a hierarchical business-related grouping. Since a feature is the FDD deliverable software increment, the team develops operational features every two weeks. Because features are small, their design and code representations are easier to inspect effectively. Project planning, scheduling, and tracking are driven by the feature hierarchy, rather than an arbitrarily adopted software engineering task set. 159 Feature template the a(n) is “a person, place, or thing E.g. Add the product to shopping cart. Display the technical-specifications of the product. Store the shipping-information for the customer. 160  A feature set groups related features into business-related categories and is defined as a (n) Ex: Making a product sale is a feature set FDD defines six milestones during the design and implementation of a feature: “design walkthrough, design, design inspection, code, code inspection, promote to build” 161  These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw- 162 Hill, 2009) Slides copyright 2009 by Dynamic Systems Development Method (DSDM) DSDM is an agile software development approach that “provides a framework for building and maintaining systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment”. The DSDM philosophy is borrowed from a modified version of the Pareto principle—80 percent of an application can be delivered in 20 percent of the time it would take to deliver the complete (100 percent) application. DSDM is an iterative software process in which each iteration follows the 80 percent rule. 163  DSDM Life cycle activities Feasibility study—establishes the basic business requirements and constraints associated with the application to be built and then assesses whether the application is a viable candidate for the DSDM process. Business study—establishes the functional and information requirements that will allow the application to provide business value; also, defines the basic application architecture and identifies the maintainability requirements for the application. Functional model iteration—produces a set of incremental prototypes that demonstrate functionality for the customer. The intent during this iterative cycle is to gather additional requirements by eliciting feedback from users as they exercise the prototype. 164  Design and build iteration—revisits prototypes built during functional model iteration to ensure that each has been engineered in a manner that will enable it to provide operational business value for end users. Implementation—places the latest software increment (an “operationalized” prototype) into the operational environment. It should be noted that (1) the increment may not be 100 percent complete or (2) changes may be requested as the increment is put into place 165 Requirements Engineering  Topics covered Requirement? Functional and Non-Functional Requirements Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management  What is a requirement? The requirements for a system are the descriptions of what the system should do—the services that it provides  Requirements engineering T h e p ro c e s s o f f i n d i n g o u t , a n a l yz i n g , documenting and checking these services and constraints is called Requirements engineering (RE). Requirements engineering is a process that involves all of the activities required to create a n d m a i n ta i n a sy ste m s re q u i re m e n t s document.  User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate. System requirements are more detailed descriptions of the software system’s functions, services, and operational constraints. The system requirements document(sometimes called a functional specification) should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.  Functional and non-functional requirements Functional requirements These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. Non-functional requirements These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Non-functional requirements often apply to the system as a whole, rather than individual system  Write a set of non-functional requirements for the ticket- issuing system, setting out its expected reliability and response time. Possible non-functional requirements for the ticket issuing system include: 1. Between 0600 and 2300 in any one day, the total system down time should not exceed 5 minutes. 2. Between 0600 and 2300 in any one day, the recovery time after a system failure should not exceed 2 minutes. 3. Between 2300 and 0600 in any one day, the total system down time should not exceed 20 minutes. All these are availability requirements – note that these vary according to the time of day. 4. After the customer presses a button on the machine, the display should be updated within 0.5 seconds. 5. The ticket issuing time after credit card validation has been received should not exceed 10 seconds. 6. When validating credit cards, the display should provide a status message for customers indicating that activity is taking place. This tells the customer that the potentially time consuming activity of validation is still in progress and that the system has not simply failed. 7. The maximum acceptable failure rate for ticket issue requests is 1: 10000. Importance of Requirements Engineering  Why Requirements Engineering? I am so proud I made the cricket ball for client to play”- the excited developer said “But you were supposed to design the Globe for me to study Geography” – the frustrated client replied. “I want something circular or elliptical” – Stakeholder (They might not know what exactly they need) I want something “Globastic” – Stakeholder (They might use some of their own strange terms)  Requirements engineering processes The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. However, there are a number of generic activities common to all processes – Requirements elicitation; – Requirements analysis; – Requirements validation; – Requirements management.  Requirements validation is the process of checking that requirements actually define the system that the customer really wants. Requirements management is the process of managing changing requirements during the requirements engineering process and system development. Requirements engineering  Feasibility studies A feasibility study decides whether or not the proposed system is worthwhile. A short focused study that checks – If the system contributes to organisational objectives; – If the system can be engineered using current technology and within budget; – If the system can be integrated with other systems that are used.  Requirements Elicitation and analysis Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. Requirements Elicitation and analysis Process  Process activities Requirements discovery – Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. Requirements classification and organisation – Groups related requirements and organises them into coherent clusters. Prioritization and negotiation – Prioritising requirements and resolving requirements conflicts. Requirements Specification – Requirements are documented and input into the next round of the spiral.  Requirements discovery The process of gathering information about the proposed and existing systems, and distilling the user and system requirements from this information. Sources of information include ü documentation, ü system stakeholders and ü the specifications of similar systems.  Problems of requirements Elicitation & Analysis Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment change. Mental health-care patient information system Stakeholders Patients whose information is recorded in the system. Doctors who are responsible for assessing and treating patients. 3. Nurses who coordinate the consultations with doctors and administer some treatments. 4. Medical receptionists who manage patients’ appointments. 5. IT staff who are responsible for installing and maintaining the system. 6. A medical ethics manager who must ensure that the system meets current ethical guidelines for patient care. 7. Healthcare managers who obtain management information from the system. 8. Medical records staff who are responsible for ensuring that system information can be maintained and preserved, and that record keeping procedures have been properly implemented.  ATM stakeholders Bank customers Representatives of other banks Bank managers Counter staff Database administrators Security managers Marketing department Hardware and software maintenance engineers Banking regulators Methods of requirements discovery Viewpoints Interviews Scenarios Use cases  Viewpoints Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints.  Types of viewpoint Interactor viewpoints – People or other systems that interact directly with the system. – Ex: In an ATM, the customer’s and the account database are interactor VPs. Indirect viewpoints – Stakeholders who do not use the system themselves but who influence the requirements. – In an ATM, management and security staff are indirect viewpoints. Domain viewpoints – Domain characteristics and constraints that influence the requirements. – In an ATM, an example would be standards for inter-bank communications. LIBSYS viewpoint hierarchy  Interviewing In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. There are two types of interview – Closed interviews where a pre-defined set of questions are answered. – Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.  Interviews in practice Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. I nte r v i ews a re n o t go o d fo r u n d e rsta n d i n g d o m a i n requirements – Requirements engineers cannot understand specific domain terminology; – Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.  Effective interviewers Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements. They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.  Scenarios Scenarios are real-life examples of how a system can be used They should include – A description of the starting situation; – A description of the normal flow of events; – A description of what can go wrong; – Information about other concurrent activities; – A description of the state when the scenario finishes. MHC-PMS scenario  Use cases Use cases are requirements discovery technique. A use case identifies the actors involved in an interaction and names the type of interaction. Use cases are documented using a high-level use case diagram. The additional information may be a textual description or one or more graphical models such as UML sequence or state charts Use cases identify the individual interactions between the system and its users or other systems. Setup consultation allows two or more doctors, working in different offices, to view the same record at the same time. One doctor initiates the consultation by choosing the people involved from a drop-down menu of doctors who are online. The patient record is then displayed on their screens but only the initiating doctor can edit the record. In addition, a text chat window is created to help LIBSYS use cases Print article sequence Withdraw cash: Actors: Customer, ATM, Accounting system Inputs: Customer’s card, PIN, Bank Account details Outputs: Customer’s card, Receipt, Bank account details Normal operation: The customer inputs his/her card into the machine. He/she s promoted for a PIN which is entered on the keypad. If correct,he/she is presented with a menu of options. The Withdraw cash option is selected. The customer is promoted with a request for the amount of cash required and inputs the amount. If there are sufficient funds in his/her account, the cash is dispensed, a receipt if printed and the account balance is updated. Before the cash is dispensed, the card is returned to the customer who is prompted by the machine to take their card. Exception: Invalid card. Card is retained by machine; Customer advised to seek advice. Incorrect PIN. Customer is request to rekey PIN. If incorrect after 3 attempts, card is retained by machine and customer advised to seek advice. Insufficient balance Transaction terminated. Card returned to customer. Display balance: Actors: Customer, ATM, Accounting system Inputs: Customer’s card, PIN, Bank Account details Outputs: Customer’s card Normal operation: The customer authenticates using card and PIN as in Withdraw cash and selects the Display Balance option. The current balance of their account is displayed on the screen. The card is returned to the customer. Exception: Invalid card. As in Withdraw cash Incorrect PIN. As in Withdraw cash Deposit cash: Actors: Customer, ATM, Accounting system Inputs: Customer’s card, PIN, Bank Account details, Cash to be deposited Outputs: Customer’s card, Receipt Normal operation: The customer authenticates as in Withdraw cash and selects the Deposit option. The customer is promoted with a request for the amount of cash to be deposited and inputs the amount. He or she is then issued with a deposit envelope in which they should put the cash then return it to the machine. The customer’s account balance is updated with the amount deposited but this is marked as uncleared funds and is not cleared until checked. A receipt is issued and the customer’s card is returned. Exception: Invalid card. As in Withdraw cash. Incorrect PIN. As in Withdraw cash. No cash deposited within 1 minute of envelope being issued. Transaction terminated. Card returned to customer.  https://www.inflectra.com/GraphicsViewer.as px?url=~/Ideas/Whitepapers/principles-of- requirements- engineering.doc&name=wordml://0300000E. png  Requirement : It is the changing need of the stakeholders which is tried to fulfill by the development team at the time of developing the product Use case : After the requirements are clear, then the use cases can be designed/decided which will clear the overall flow of the system to developers first and then they can design the system accordingly. Once the flow is clear to them, then it becomes somehow simple to test the system by QA. Scenario : It is the real life situation in which the end-user/customer uses/interacts with the system and came across various failures(if there are any). Hence we generally used to say Real world scenario. Example: For a particular project the requirements are first being made