KateelDurgaSWEngg01V001.pdf

Software Engineering Welcome We will start soon…. Software Engineering Vinaya Sathyanarayana Book  Unit 1 Software and Software Engineering Nature of Software – Defining Software Software is: 1) Instructions (computer programs) that when executed...

Software Engineering Welcome We will start soon…. Software Engineering Vinaya Sathyanarayana Book  Unit 1 Software and Software Engineering Nature of Software – Defining Software Software is: 1) Instructions (computer programs) that when executed provide desired features, function, and performance; 2) Data structures that enable the programs to adequately manipulate information. 3) Documentation that describes the operation and use of the programs. 5 What is Software? Software is developed or engineered it is not manufactured in the classical sense. Software doesn't "wear out“ but is does deteriorate. Although the industry is moving toward component-based construction, most software continues to be custom-built. 6 Software Application Domains System software. Application software. Engineering/Scientific software. Embedded software. Product-line software. Web/Mobile applications. AI software (robotics, neural nets, game playing). 7 Wear versus Deterioration Access the text alternative for slide images. 8 Legacy Software Why must software change? Software must be adapted to meet the needs of new computing environments or technology. Software must be enhanced to implement new business requirements. Software must be extended to make it interoperable with other more modern systems or databases. Software must be re-architected to make it viable within a network environment. 9 Defining the Discipline 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). 10 Software Engineering Layers 11 Process Framework Activities Communication. Planning. Modeling. Analysis of requirements. Design. Construction: Code generation. Testing. Deployment. 12 Umbrella Activities Software project tracking and control. Risk management. Software quality assurance. Technical reviews. Measurement. Software configuration management. Reusability management. Work product preparation and production. 13 Process Difference Requiring Adaptation Overall flow of activities, actions, and tasks and the interdependencies among them. Degree to which actions and tasks are defined within each framework activity. Degree to which work products are identified and required. Manner which quality assurance activities are applied. Manner in which project tracking and control activities are applied. Overall degree of detail and rigor with which the process is described. Degree to which the customer and other stakeholders are involved with the project. Level of autonomy given to the software team. Degree to which team organization and roles are prescribed. 14 Essence of Software Engineering Practice Polya suggests: 1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design). 3. Carry out the plan (code generation). 4. Examine result for accuracy (testing & quality assurance). 15 Understand the Problem Who has a stake in the solution to the problem? That is, who are the stakeholders? What are the unknowns? What data, functions, and features are required to properly solve the problem? Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand? Can the problem be represented graphically? Can an analysis model be created? 16 Plan a Solution Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required? Has a similar problem been solved? If so, are elements of the solution reusable? Can subproblems be defined? If so, are solutions readily apparent for the subproblems? Can you represent a solution in a manner that leads to effective implementation? Can a design model be created? 17 Carryout the Plan Does the solution conform to the plan? Is source code traceable to the design model? Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm? 18 Examine the Result Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented? Does the solution produce results, that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements? 19 Hooker’s General Principles 1. The Reason It All Exists – provide value to users. 2. KISS (Keep It Simple, Stupid!) – design simple as it can be. 3. Maintain the Vision – clear vision is essential. 4. What You Produce, Others Will Consume. 5. Be Open to the Future - do not design yourself into a corner. 6. Plan Ahead for Reuse – reduces cost and increases value. 7. Think! – placing thought before action produce results. 20 How it all Starts – SafeHome Begins Every software project is precipitated by some business need— The need to correct a defect in an existing application; The need to the need to adapt a ‘legacy system’ to a changing business environment; The need to extend the functions and features of an existing application, or The need to create a new product, service, or system. 21 Unit 2 Process Models Generic Process Model Access the text alternative for slide images. 23 Process Flow Access the text alternative for slide images. 24 Identifying a Task Set A task set defines the actual work to be done to accomplish the objectives of a software engineering action. A task set is defined by creating several lists: A list of the tasks to be accomplished. A list of the work products to be produced. A list of the quality assurance filters to be applied. 25 Process Assessment and Improvement The existence of a software process is no guarantee that software will be delivered on time, or meet the customer’s needs, or that it will exhibit long-term quality characteristics. Any software process can be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for successful software engineering. Software processes and activities should be assessed using numeric measures or software analytics (metrics). 26 Prescriptive Process Models 1 Prescriptive process models advocate an orderly approach to software engineering. That leads to a two questions: If prescriptive process models strive for structure and order, are they appropriate for a software world that thrives on change? If we reject traditional process models and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? 27 Waterfall Process Model Pros It is easy to understand and plan. It works for well-understood small projects. Analysis and testing are straightforward. Cons It does not accommodate change well. Testing occurs late in the process. Customer approval is at the end. Access the text alternative for slide images. 28 Prototyping Process Model Pros Reduced impact of requirement changes. Customer is involved early and often. Works well for small projects. Reduced likelihood of product rejection. Cons Customer involvement may cause delays. Temptation to “ship” a prototype. Work lost in a throwaway prototype. Hard to plan and manage. Access the text alternative for slide images. 29 Spiral Process Model Pros Continuous customer involvement. Development risks are managed. Suitable for large, complex projects. It works well for extensible products. Cons Risk analysis failures can doom the project. Project may be hard to manage. Requires an expert development team. Access the text alternative for slide images. 30 Unified Process Model Pros Quality documentation emphasized. Continuous customer involvement. Accommodates requirements changes. Works well for maintenance projects. Cons Use cases are not always precise. Tricky software increment integration. Overlapping phases can cause problems. Requires expert development team. Access the text alternative for slide images. 31 Prescriptive Process Models 2 Prescriptive process models advocate an orderly approach to software engineering. That leads to a two questions: If prescriptive process models strive for structure and order, are they appropriate for a software world that thrives on change? If we reject traditional process models and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? 32  Unit 3 Agility and Process What is Agility? Effective (rapid and adaptive) response to change. Effective communication among all stakeholders. Drawing the customer onto the team. Organizing a team so that it is in control of the work performed. Rapid, incremental delivery of software. 34 Agility and Cost of Change Access the text alternative for slide images. 35 What is an Agile Process? Driven by customer descriptions of what is required (scenarios). Customer feedback is frequent and acted on. Recognizes that plans are short-lived. Develops software iteratively with a heavy emphasis on construction activities. Delivers multiple ‘software increments’ as executable prototypes. Adapts as project or technical changes occur. 36 Agility Principles 1 Customer satisfaction is achieved by providing value through software that is delivered to the customer as rapidly as possible. Develop recognize that requirements will change and welcome changes. Deliver software increments frequently (weeks not months) to stakeholders to ensure feedback on their deliveries is meaningful. Agile team populated by motivated individuals using face-to- face communication to convey information. Team process encourages technical excellence, good design, simplicity, and avoids unnecessary work. 37 Agility Principles 2 Working software that meets customer needs is the primary goal. Pace and direction of the team’s work must be “sustainable,” enabling them to work effectively for long periods of time. An agile team is a “self-organizing team”—one that can be trusted develop well-structured architectures that lead to solid designs and customer satisfaction. Part of the team culture is to consider its work introspectively with the intent of improving how to become more effective its primary goal (customer satisfaction). 38 Scrum Framework Access the text alternative for slide images. 39 Scrum Details Backlog Refinement Meeting Developers Pros work with stakeholders to create product Product owner sets priorities. backlog. Team owns decision making. Sprint Planning Meeting Backlog Documentation is lightweight. partitioned into “sprints” derived from Supports frequent updating. backlog and next sprint defined. Daily Scrum Meeting Team members synchronize their activities and plan work Cons day (15 minutes max). Difficult to control the cost of Sprint Review Prototype “demos” are changes. delivered to the stakeholders for approval or May not be suitable for large rejection. teams. Sprint Retrospective After sprint is Requires expert team members. complete, team considers what went well and what needs improvement. 40 Extreme Programming (XP) Framework Access the text alternative for slide images. 41 XP Details XP Planning – Begins with user stories, Pros team estimates cost, stories grouped into Emphasizes customer involvement. increments, commitment made on Establishes rational plans and delivery date, computer project velocity. schedules. XP Design – Follows KIS principle, High developer commitment to the encourages use of CRC cards, design project. prototypes, and refactoring. Reduced likelihood of product XP Coding – construct unit tests before rejection. coding, uses pair. XP Testing – unit tests executed daily, Cons acceptance tests define by customer. Temptation to “ship” a prototype. Requires frequent meetings about increasing costs. Allows for excessive changes. Depends on highly skilled team members. 42 Kanban Framework Access the text alternative for slide images. 43 Kanban Details Visualizing workflow using a Kanban Pros board. Lower budget and time requirements. Limiting the amount of work in Allows early product delivery. progress at any given time. Process policies written down. Managing workflow to reduce waste by understanding the current value Continuous process improvement. flow. Cons Making process policies explicit and the criteria used to define “done”. Team collaboration skills determine success. Focusing on continuous improvement by creating feedback loops where Poor business analysis can doom the changes are introduced. project. Make process changes collaboratively Flexibility can cause developers to lose and involve all stakeholders as focus. needed. Developer reluctance to use measurement. 44 DevOps Access the text alternative for slide images. 45 DevOps Details Continuous development. Software Pros delivered in multiple sprints. Reduced time to code deployment. Continuous testing. Automated Team has developers and operations testing tools used prior to staff. integration. Team has end-to-end project ownership. Continuous integration. Code Proactive monitoring of deployed pieces with new functionality added product. to existing code running code. Continuous deployment. Integrated Cons code is deployed to the production environment. Pressure to work on both old and new code. Continuous monitoring. Team Heavy reliance on automated tools to be operations staff members effective. proactively monitor software performance in the production Deployment may affect the production environment. environment. Requires an expert development team. 46  Unit 4 Recommended Process Model Adapting Process Models Every software project needs a “road map” or “generic software process” of some kind. Every project is different, and every team is different. No single software engineering framework is appropriate for every software product. Any road map or generic process should be based on best industry practices. Developers and stakeholders adapt generic process models and tailor them to fit the current project, the skills of the team members, and the user needs. 48 Principles for Organizing Software Projects 1. It is risky to use a linear process model without ample feedback. 2. It is never possible nor desirable to plan big up-front requirements gathering. 3. Up-front requirements gathering may not reduce costs or prevent time slippage. 4. Appropriate project management is integral to software development. 5. Documents should evolve with the software and should not delay the start of construction. 6. Involve stakeholders early and frequently in the development process. 49 Incremental Model for Prototype Design Access the text alternative for slide images. 50 Characteristics of Agile Process Models 1. Not suitable for large high-risk or mission critical projects. 2. Minimal rules and minimal documentation. 3. Continuous involvement of testers. 4. Easy to accommodate product changes. 5. Depends heavily on stakeholder interaction. 6. Easy to manage. 7. Early delivery of partial solutions. 8. Informal risk management. 9. Built-in continuous process improvement. 51 Characteristics of Spiral Process Models 1. Not suitable for small, low-risk projects. 2. Several steps required, along with documentation done up front. 3. Early involvement of testers (might be done by outside team). 4. Hard to accommodate product changes until prototype completed. 5. Continuous stakeholder involvement in planning and risk assessment. 6. Requires formal project management and coordination. 7. Project end not always obvious. 8. Good risk management. 52 Spiral Model for Prototype Design Access the text alternative for slide images. 53 Agile Requirements Definition 1 1. Encourage active stakeholder participation by matching their availability and valuing their input. 2. Use simple models (for example, Post-it notes, fast sketches, user stories) to reduce barriers to participation. 3. Take time to explain your requirement representation techniques before using them. 4. Adopt stakeholder terminology and avoid technical jargon whenever possible. 5. Use a breadth-first approach to get the big picture of the project done before getting bogged down in details. 54 Agile Requirements Definition 2 6. Developer and stakeholders refine requirements “just in time” as user stories are ready to be implemented. 7. Treat list of features like a prioritized list and implement the most important user stories first. 8. Collaborate closely with stakeholders and document requirements so they ares useful to all when creating the next prototype. 9. Question the need to maintain models and documents not referred to in the future. 10.Ensure management support for stakeholder and resource availability during requirements definition. 55 Protype Architectural Design Access the text alternative for slide images. 56 Elements of Agile Architectural Design 1. Focus on key quality attributes and incorporate them into prototypes as they are constructed. 2. Keep in mind that successful software products combine customer-visible features and the infrastructure needed to enable them. 3. Agile architectures enable code maintainability and evolvability if attention is paid to architectural decisions and quality issues. 4. Managing and synchronizing dependencies among functional and architectural requirements is needed to ensure evolving architecture will be ready for future increments. 57 Resource Estimation for Agile Spiral Model 1. Team should use historic data to develop an estimate of number of days needed to complete each of user stories known at the start of the project. 2. Loosely organize the user stories into sets that will make up each sprint planned to complete a prototype. 3. Sum the number of days to complete each sprint to provide an estimate for the duration of the total project. 4. Revise the estimate as requirements are added to the project or prototypes are delivered and accepted by the stakeholders. 58 First Prototype Guidelines 1. Transition from paper prototype to software design. 2. Prototype a user interface. 3. Create a virtual prototype. 4. Add input and output to your prototype. 5. Engineer your algorithms. 6. Test your prototype. 7. Prototype with deployment in mind. 59 Prototype Evaluation 1. Provide scaffolding when asking for prototype feedback. 2. Test your prototype on the right people. 3. Ask the right questions. 4. Be neutral when presenting alternatives to users. 5. Adapt while testing. 6. Allow the user to contribute ideas. 60 Go No Go Decision A pass through the planning region follows the evaluation process. Revised cost estimates and schedule changes are proposed based on changes were requested when evaluating the current prototype. Risk of exceeding the budget and missing the project delivery date is assessed. Risk of failing to satisfy user expectations is also considered and discussed with the stakeholders and sometimes senior management. Goal of risk assessment is to get commitment from stakeholders and management to provide the resources needed to create the next prototype. 61 Recommended Prototype Evolutionary Process Access the text alternative for slide images. 62 Recommended Process Steps 1 1. Requirements engineering. Gather user stories from all stakeholders. Have stakeholders describe acceptance criteria user stories. 2. Preliminary architectural design. Make use of paper prototypes and models. Assess alternatives using nonfunctional requirements. Document architecture design decisions. 3. Estimate required project resources. Use historic data to estimate time to complete each user story. Organize the user stories into sprints. Determine the number of sprints needed to complete the product. Revise the time estimates as use stories are added or deleted. 63 Recommended Process Steps 2 4. Construct first prototype. Select subset of user stories most important to stakeholders. Create paper prototype as part of the design process. Design a user interface prototype with inputs and outputs. Engineer the algorithms needed for first prototypes. Prototype with deployment in mind. 5. Evaluate prototype. Create test cases while prototype is being designed. Test prototype using appropriate users. Capture stakeholder feedback for use in revision process. 64 Recommended Process Steps 3 6. Go, No-Go decision. Determine the quality of the current prototype. Revise time and cost estimates for completing development. Determine the risk of failing to meet stakeholder expectations. Get commitment to continue development. 7. Evolve system. Define new prototype scope. Construct new prototype. Evaluate new prototype and include regression testing. Assess risks associated with continuing evolution. 65 Recommended Process Steps 4 8. Release prototype. Perform acceptance testing. Document defects identified. Share quality risks with management. 9. Maintain software. Understand code before making changes. Test software after making changes. Document changes. Communicate known defects and risks to all stakeholders. 66 Testing New Prototypes Testing should be performed by developers using test cases created during the design process before programming was completed. Each user story has an acceptance criteria attached to it and it should guide the creation of the test cases to ensure the prototype meets customer needs. Prototypes need to be tested for defects and performance issues. Ensure that adding new features to evolutionary prototypes does not accidentally break features working correctly in the previous prototype (regression testing). 67 Release Candidates 1 A prototype considered as a release candidate is subjected to user acceptance testing in addition to testing conducted during prototype construction. User acceptance tests are based on acceptance criteria that were recorded as each user story was created and added to the product backlog. User feedback during acceptance testing should be organized by user-visible functions as portrayed via the user interface. Developers should make changes only if these changes will not delay the release of the prototype. 68 Release Candidates 2 If changes are made, they need to be verified in a second round of acceptance testing before moving on. The issues and lessons learned from creating the release candidate should be documented and considered by the developers and stakeholders as part of the project postmortem. This information should be considered before deciding to undertake future development of a software product. Lessons learned from the current product can help developers make better cost and time estimates for similar projects in the future. 69 Software Release Maintenance Maintenance - activities needed to keep software operational after it has been accepted and released in the end-user environment. Corrective maintenance - reactive modification of software to repair problems discovered after the software has been delivered. Adaptive maintenance - reactive modification of software after delivery to keep the software usable in a changing environment. Perfective maintenance - proactive modification of the software after delivery to provide new user features, better program code structure, or improved documentation. Preventive maintenance – proactive modification software after delivery to correct product faults before discovery by users. In agile process models much (but not all) of the maintenance work is preventive or perfective as new features are added. 70 Maintenance Effort Distribution Access the text alternative for slide images. 71  Unit 5 Human aspects of SW Engineering Traits of Successful Software Engineers Sense of individual responsibility. Acutely aware of the needs of team members and stakeholders. Brutally honest about design flaws and offers constructive criticism. Resilient under pressure. Heightened sense of fairness. Attention to detail. Pragmatic adapting software engineering practices based on the circumstances at hand. 73 Behavior Model for Software Engineering Source: Adapted from Curtis, Bill, and Walz, Diane, “The Psychology of Programming in the Large: Team and Organizational Behavior,” Psychology of Programming, Academic Press, 1990. Access the text alternative for slide images. 74 Effective Software Team Attributes Sense of purpose. Sense of involvement. Sense of trust. Sense of improvement. Diversity of team member skill sets. 75 Symptoms of Team Toxicity A frenzied work atmosphere where team members waste energy and lose focus on work objectives. High frustration that causes friction among team members. Fragmented or poorly coordinated software process model that becomes a roadblock to accomplishment. Unclear definition of team roles resulting in a lack of accountability and resultant finger-pointing. Continuous and repeated exposure to failure that leads to a loss of confidence and poor morale. 76 Project Factors Affecting Team Structure Difficulty of the problem to be solved. Resultant program size in lines of code or function points. Time that the team will stay together (team lifetime). Degree to which the problem can be modularized. Required quality and reliability of the system to be built. Rigidity of the delivery date. Degree of communication required for the project. 77 Agile Teams Stress individual competency coupled with group collaboration as critical success factors. People trump process and politics can trump people. Agile teams as self-organizing and have many structures. Adaptive team structures. Significant autonomy. Communication among developers and stakeholders is important (consider adding customer rep to team). Planning is kept to a minimum and constrained only by business requirements and organizational standards. 78 Impact of Social Media Social processes around software development are highly depend on engineers’ abilities to connect with individuals who share similar goals and complementary skills. Value of social networking tools grows as team size increases or when a team is geographically dispersed. Privacy and security issues should not be overlooked when using social media for software engineering work. Benefits of social media must be weighed against the threat of uncontrolled disclosure of proprietary information. 79 Team Decision Making Complications Problem complexity. Uncertainty and risk associated with the decision. Work associated with decision has unintended effect on another project object (law of unintended consequences). Different views of the problem lead to different conclusions about the way forward. Global software teams face additional challenges associated with collaboration, coordination, and communication difficulties. 80 Factors Affecting Global Software Development Teams Access the text alternative for slide images. 81  Unit 6 Principles that Guide Practice Principles that Guide Process 1 Principle #1. Be agile. Regards of your process model, let the basic tenets of agile development govern your approach. Principle #2. Focus on quality at every step. The exit condition for every process activity, action, and task should focus on the quality of the work product produced. Principle #3. Be ready to adapt. Dogma has no place in software development. Adapt your approach to constraints imposed by the problem, the people, and the project itself. Principle #4. Build an effective team. Software engineering process and practice are important, but the bottom line is people. Build a self-organizing team. 83 Principles that Guide Process 2 Principle #5. Establish mechanisms for communication and coordination. Projects fail because information falls into the cracks and/or stakeholders fail to coordinate their efforts. Principle #6. Manage change. Approach may formal or informal. You need mechanisms to manage how changes are requested, assessed, approved and implemented. Principle #7. Assess risk. Lots of things can go wrong as software is being developed, establish contingency plans. Principle #8. Create work products that provide value for others. Create only those work products that provide value for other process activities, actions or tasks. 84 Principles that Guide Practice 1 Principle #1. Divide and conquer. Analysis and design should always emphasize separation of concerns (SoC). Principle #2. Understand the use of abstraction. Abstraction is a simplification of a complex system element used to communication meaning simply. Principle #3. Strive for consistency. A familiar context makes software easier to use. Principle #4. Focus on the transfer of information. Pay special attention to the analysis, design, construction, and testing of interfaces. 85 Principles that Guide Practice 2 Principle #5. Build software that exhibits effective modularity. Provides a mechanism for realizing the philosophy of Separation of concerns. Principle #6. Look for patterns. The goal of patterns is to create a body of literature to help developers resolve recurring problems encountered in software development. Principle #7. Use multiple viewpoints. Represent the problem and solution from different perspectives. Principle #8. Some consumes your work products. Remember that someone will maintain the software. 86 Simplified Process Framework Access the text alternative for slide images. 87 Communications Principles 1 Principle #1. Listen. Try to focus on the speaker’s words, not formulating your response to those words. Principle # 2. Prepare before you communicate. Understand a problem before meeting with others. Principle # 3. Someone should facilitate the activity. Every communication meeting should have a leader to keep the conversation moving in a productive direction. Principle #4. Face-to-face communication is best. Visual representations of information can be helpful. Principle # 5. Take notes and document decisions. Someone should serve as a “recorder” and write down all important points and decisions. 88 Communications Mode Effectiveness Access the text alternative for slide images. 89 Communications Principles 2 Principle # 6. Strive for collaboration. Consensus occurs when collective team knowledge is combined. Principle # 7. Stay focused, modularize your discussion. The more people involved in communication the more likely discussion will bounce between topics. Principle # 8. If something is unclear, draw a picture. Principle # 9. (a) Once you agree to something, move on; (b) If you can’t agree to something, move on; (c) If a feature or function is unclear and cannot be clarified at the moment, move on. Principle # 10. Negotiation is not a contest or a game. It works best when both parties win. 90 Iterative Planning Process Access the text alternative for slide images. 91 Planning Principles 1 Principle #1. Understand the scope of the project. Scope provides the software team with a destination as the roadmap is created. Principle #2. Involve the customer in the planning activity. They define priorities and project constraints. Principle #3. Recognize that planning is iterative. A project plan is likely to change as work begins. Principle #4. Estimate based on what you know. Estimation provides an indication of effort, cost, and task duration, based on team’s current understanding of work. Principle #5. Consider risk as you define the plan. Contingency planning is needed for identified high impact and high probability risks. 92 Planning Principles 2 Principle #7. Adjust granularity as you define the plan. Granularity refers to the level of detail that is introduced as a project plan is developed. Principle #8. Define how you intend to ensure quality. Your plan should identify how the software team intends to ensure quality. Principle #9. Describe how you intend to accommodate change. Even the best planning can be obviated by uncontrolled change. Principle #10. Track the plan frequently and make adjustments as required. Software projects fall behind schedule one day at a time. 93 Software Modeling Access the text alternative for slide images. 94 Agile Modeling Principles 1 Principle #1. The primary goal of the software team is to build software not create models. Principle #2. Travel light – don’t create more models than you need. Principle #3. Strive to produce the simplest model that will describe the problem or the software. Principle #4. Build models in a way that makes them amenable to change. Principle #5. Be able to state an explicit purpose for each model that is created. 95 Agile Modeling Principles 2 Principle #6. Adapt the models you create to the system at hand. Principle #7. Try to build useful models, forget abut building perfect models. Principle #8. Don’t become dogmatic about model syntax. Successful communication is key. Principle #9. If your instincts tell you a paper model isn’t working you may have a reason to be concerned. Principle #10. Get feedback as soon as you can. 96 Construction Principles - Coding 1 Preparation Principles: Before you write one line of code, be sure you: Principle 1. Understand the problem to be solved. Principle 2. Understand basic design principles and concepts. Principle 3. Pick a programming language that meets the needs of the software to be built. Principle 4. Select a programming environment that provides tools that will make your work easier. Principle 5. Create a set of unit tests that will be applied once the component you code is completed. 97 Construction Principles - Coding 2 Coding Principles: As you begin writing code, be sure you: Principle 6. Constrain your algorithms by following structured programming practice. Principle 7. Consider the use of pair programming. Principle 8. Select data structures that will meet the needs of the design. Principle 9. Understand the software architecture and create interfaces that are consistent with it. 98 Construction Principles - Coding 3 Validation Principles: After you’ve completed your first coding pass, be sure you: Principle 10. Conduct a code walkthrough when appropriate. Principle 11. Perform unit tests and correct errors you’ve uncovered. Principle 12. Refactor the code to improve its quality. 99 Agile Testing Access the text alternative for slide images. 100 Testing Principles 1 Principle #1. All tests should be traceable to customer requirements. Principle #2. Tests should be planned long before testing begins. 1. Testing is a process of executing a program with intent of finding an error, 2. A good test case is one that has a high probability of finding an as-yet- undiscovered error. 3. A successful test is one that uncovers an as-yet-undiscovered error. Principle #3. The Pareto principle applies to software testing. 101 Testing Principles 2 Principle #4. Testing should begin “in the small” and progress toward testing “in the large.” Principle #5. Exhaustive testing is not possible. Principle #6. Testing effort for each system module commensurate to expected fault density. Principle #7. Static testing can yield high results. Principle #8. Track defects and look for patterns in defects uncovered by testing. Principle #9. Include test cases that demonstrate software is behaving correctly. 102 Software Deployment Actions Access the text alternative for slide images. 103 Deployment Principles 1 Principle #1. Customer expectations for the software must be managed. Principle #2. A complete delivery package should be assembled and tested. Principle #3. A support regime must be established before the software is delivered. Principle #4. Appropriate instructional materials must be provided to end-users. Principle #5. Buggy software should be fixed first, delivered later. 104  Unit 7 Understanding Requirements Requirements Engineering 1 Inception - establish a basic understanding of the problem, the people who want a solution, and the nature of the solution that is desired, important to establish effective customer and developer communication. Elicitation - elicit requirements and business goals form from all stakeholders. Elaboration - focuses on developing a refined requirements model that identifies aspects of software function, behavior, and information. 106 Requirements Engineering 2 Negotiation—agree on the scope of a deliverable system that is realistic for developers and customers. Specification—can be any or all of the following: written documents, graphical models, mathematical models, usage scenarios, prototypes. Validation—Requirements engineering work products produced during requirements engineering are assessed for quality and consistency. Requirements management – set of traceability activities to help the project team identify, control, and track requirements and their changes to requirements as the project proceeds. 107 Non-functional Requirements Non-Functional Requirement (NFR) – quality attribute, performance attribute, security attribute, or general system constraint. A two-phase process is used to determine which NFR’s are compatible: The first phase is to create a matrix using each NFR as a column heading and the system SE guidelines a row labels. The second phase is for the team to prioritize each NFR using a set of decision rules to decide which to implement by classifying each NFR and guideline pair as complementary, overlapping, conflicting, or independent. 10 Establishing the Groundwork Identify stakeholders. “who else do you think I should talk to?” Recognize multiple points of view. Work toward collaboration. The first questions. Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution that you need? 109  Collaborative Requirements Gathering Meetings (real or virtual) are conducted and attended by both software engineers and other stakeholders. Rules for preparation and participation are established. Agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas. A “facilitator” (customer, developer, or outsider) controls the meeting. ∙A “definition mechanism” (worksheets, flip charts, wall stickers or virtual forum) is used. Goal is to identify the problem, propose solution elements, and negotiate different approaches. 110 Elicitation Work Products Statement of need and feasibility. Bounded statement of scope for the system or product. List of customers, users, and other stakeholders who participated in requirements elicitation, Description of the system’s technical environment. List of requirements (preferably organized by function) and the domain constraints that apply to each. Set of usage scenarios (written in stakeholders’ own words) that provide insight into the use of the system or product under different operating conditions. 111 Use Case Definition A collection of user scenarios that describe the thread of usage of a system Each scenario is described from the point-of-view of an “actor” - a person or device that interacts with the software in some way Each scenario answers the following questions: Who is the primary actor, the secondary actor (s)? What are the actor’s goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What extensions might be considered as the story is described? What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? 112 Analysis Model Elements Analysis model provides a description of the required informational, functional, and behavioral domains for a computer-based system. Scenario-based elements – functional descriptions are express in the customers own words and user stories and as interactions of actors with the system expressed using UM L use case diagrams. Class-based elements – collections of attributes and behaviors implied by the user stories and expressed using UML class diagrams (information domain). Behavioral elements – may be expressed using UML state diagrams as inputs causing state changes. 113 UML Use Case Diagram Access the text alternative for slide images. 114 UML Class Diagram Access the text alternative for slide images. 115 UML State Diagram Access the text alternative for slide images. 116 Analysis Patterns Pattern name: A descriptor that captures the essence of the pattern. Intent: Describes what the pattern accomplishes or represents. Motivation: A scenario that illustrates how the pattern can be used to address the problem. Forces and context: A description of external issues (forces) that can affect how the pattern is used and the external issues that will be resolved when the pattern is applied. Solution: A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues. Consequences: Addresses what happens when the pattern is applied and what trade-offs exist during its application. Design: Discusses how the analysis pattern can be achieved through the use of known design patterns. Known uses: Examples of uses within actual systems. Related patterns: On e or more analysis patterns that are related to the named pattern because (1) it is commonly used with the named pattern; (2) it is structurally similar to the named pattern; (3) it is a variation of the named pattern. 117 Negotiating Requirements Negotiations strive for a “win-win” result, stakeholders win by getting a product satisfying most of their needs and developers win by getting achievable deadlines. Handshaking is one-way to achieve “win-win”. Developers propose solutions to requirements, describe their impact, and communicate their intentions to the customers. Customer review the proposed solutions, focusing on missing features and seeking clarification of novel requirements. Requirements are determined to be good enough if the customers accept the proposed solutions. Handshaking tends to improve identification, analysis, and selection of variants. 118 Requirements Monitoring Useful for incremental development includes: 1. Distributed debugging - uncovers errors and determines their cause. 2. Run-time verification - determines whether software matches its specification. 3. Run-time validation - assesses whether the evolving software meets user goals. 4. Business activity monitoring - evaluates whether a system satisfies business goals. 5. Evolution and codesign - provides information to stakeholders as the system evolves. 119 Validating Requirements 1 Is each requirement consistent with the overall objective for the system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Do any requirements conflict with other requirements? 120 Validating Requirements 2 Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Does the requirements model properly reflect the information, function and behavior of system to be built? Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system? Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements? 121  Unit 8 Requirements Modeling Requirements Analysis Requirements analysis specifies software’s operational characteristics. indicates software's interface with other system elements. establishes constraints that software must meet. Requirements analysis allows the software engineer to: elaborate on basic requirements established during earlier requirement engineering tasks. build models that depict the user’s needs from several different perspectives. 123 Requirements Models Scenario-based models depict requirements from the point of view of various system “actors.” Class-oriented models represent object-oriented classes (attributes and operations) and how classes collaborate to achieve system requirements. Behavioral models depict how the software reacts to internal or external “events.” Data models depict the information domain for the problem. Flow-oriented models represent functional elements of the system and how they transform data in the system. 124 A Bridge Access the text alternative for slide images. 125 Rules of Thumb The level of abstraction should be relatively high - focus on requirements visible in problem or business domains. Analysis model should provide insight into information domain, function, and behavior of the software. Delay consideration of infrastructure and other non-functional models until later in the modeling activity. The analysis model provides value to all stakeholders keep the model as simple as it can be. 126 Requirements Modeling Principles Principle 1. The information domain of a problem must be represented and understood. Principle 2. The functions that the software performs must be defined. Principle 3. The behavior of the software (as a consequence of external events) must be represented. Principle 4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. Principle 5. The analysis task should move from essential information toward implementation detail. 127 Scenario-Based Modeling: Actors and Profiles A UML actor models an entity that interacts with a system object. Actors may represent roles played by human stakeholders or external hardware as they interact with system objects by exchanging information. A UML profile provides a way of extending an existing model to other domains or platforms. This might allow you to revise the model of a Web-based system and model the system for various mobile platforms. Profiles might also be used to model the system from the viewpoints of different users. 128 Use Cases Use case as a “contract for behavior” and more formal than a user story. Use-cases are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases). 1. What should we write about? 2. How much should we write about it? 3. How detailed should we make our description? 4. How should we organize the description? 129 What to Write About? The first two requirements engineering tasks—inception and elicitation—provide you with the information you’ll need to begin writing use cases. To begin developing a set of use cases, list the functions or activities performed by a specific actor. You can obtain these from a list of required system functions, through conversations with stakeholders, or by an evaluation of activity diagrams developed as part of requirements modeling. Use cases of this type are sometimes referred to as primary scenarios. 130 Alternative Interactions Description of alternative interactions is essential to completely understand a function described a use case. Can the actor take some other action at this point? Is it possible that the actor will encounter some error condition at this point? Is it possible that the actor will encounter some other behavior at this point (for example: behavior that is invoked by some event outside the Answers actor’squestions to these control)?result in the creation of a set of secondary scenarios represent alternative use cased behavior. 131 Defining Exceptions An exception describes a situation (either a failure condition or an alternative chosen by the actor) that causes the system to exhibit somewhat different behavior. Questions to ask: Are there cases in which some “validation function” occurs during this use case? Are there cases in which a supporting function (or actor) will fail to respond appropriately? Can poor system performance result in unexpected or improper user actions? 132 Documenting Use Cases What are the main tasks or functions that are performed by the actor? What system information will the actor acquire, produce or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? What are the preconditions, triggers, exceptions, and open issues? 133 Use Case Diagram Access the text alternative for slide images. 134 Class-Based Modeling Class-based modeling represents: objects that the system will manipulate. operations (also called methods or services) that will be applied to the objects to effect the manipulation. relationships (some hierarchical) between the objects. collaborations that occur between the classes that are defined. The elements of a class-based model include classes and objects, attributes, operations, CRC models, UML class diagrams. 135 Identifying Analysis Classes Examining the usage scenarios developed as part of the requirements model and perform a "grammatical parse“. Classes are determined by underlining each noun or noun phrase and entering it into a simple table. Synonyms should be noted. If the class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is necessary only to describe a solution, it is part of the problem space. But what should we look for once all of the nouns have been isolated? 136  Potential Analysis Classes External entities (for example: other systems, devices, people) that produce or consume information. Things (for example: reports, displays, letters, signals) that are part of the information domain for the problem. Occurrences or events that occur within the context of system operation. Roles played by people who interact with the system. Organizational units that are relevant to an application. Places that establish the context of the problem and overall function. Structures (for example: sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects. 137  Analysis Class Selection Retained information. Potential class will be useful during analysis only if information about it must be remembered. Needed services. Potential class must have a set of identifiable operations that can change the value of its attributes in some way. Multiple attributes. Focus should be on "major" information; a class with a single attribute may be better represented as an attribute of another class. Common attributes. A set of attributes can be defined for the potential class and the attributes apply to all instances of the class. Common operations. A set of operations can be defined for the potential class and the operations apply to all instances of the class. Essential requirements. External entities that appear in the problem space and produce or consume information essential to the solution will usually be defined as analysis classes in the model. 138  Defining Attributes Attributes describe a class that has been selected for inclusion in the analysis model. It is the attributes that define the class—that clarify what is meant by the class in the context of the problem space. To develop a meaningful set of attributes for an analysis class, you should study each use case and select those “things” that reasonably “belong” to the class. What data items(composite and/or elementary) fully define this class in the context of the problem at hand? 139  Defining Operations Operations define the behavior of an object. Operations they can generally be divided into four broad categories: 1. Operations that manipulate data in some way. 2. Operations that perform a computation. 3. Operations that inquire about the state. 4. Operations that monitor an object for the occurrence of a controlling event. These functions are accomplished by operating on attributes and/or associations. Therefore, an operation must have “knowledge” of the class attributes and associations. 140 CRC Modeling Class-responsibility-collaborator (CRC) modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections: 1. Along the top of the card you write the name of the class. 2. list the class responsibilities on the left. 3. list the collaborators on the right. 141 CRC Cards Access the text alternative for slide images. 142  CRC Model Review Process 1. All stakeholders in the review (of the CRC model) are given a subset of the CRC model index cards. No reviewer should have two cards that collaborate. 2. The review leader reads the use case deliberately. As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card. 3. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one of the responsibilities satisfies the use case requirement. 4. If an error is found, modifications are made to the cards. This may include the definition of new classes (CRC index cards) or revising lists of responsibilities or collaborations on existing cards. 143 Functional Modeling The functional model addresses two application processing elements: 1. user-observable functionality that is delivered by the app to end users. 2. operations contained within analysis classes that implement behaviors associated with the class. UML activity diagrams can be used to represent processing details. UML activity diagram supplements a use case by providing a graphical representation of the flow of interaction within a specific scenario. 144 Activity Diagram 1 Access the text alternative for slide images. 145 Sequence Diagram 1 The UML sequence diagram can be used for behavioral modeling. Sequence diagrams can also be used to show how events cause transitions from object to object. Once events have been identified by examining a use case, the modeler creates a sequence diagram—a representation of how events cause flow from one object to another as a function of time. Sequence diagram is a shorthand version of a use case. 146 Sequence Diagram 2 Access the text alternative for slide images. 147 Behavioral Modeling A behavioral model indicates how software will respond to internal or external events or stimuli. This information is useful in the creation of an effective design for the system to be built. UML activity diagrams can be used to model how system elements respond to internal events. UML state diagrams can be used to model how system elements respond to external events. 148 Creating Behavioral Models 1. Evaluate all use cases to fully understand the sequence of interaction within the system. 2. Identify events that drive the interaction sequence and understand how these events relate to specific objects. 3. Create a sequence diagram for each use case. 4. Build a state diagram for the system. 5. Review the behavioral model for accuracy and consistency. 149 Identifying Events A use case represents a sequence of activities that involves actors and the system. An event occurs whenever the system and an actor exchange information. An event is not the information that has been exchanged, but rather the fact that information has been exchanged. A use case needs to be examined for points of information exchange. Events are used to trigger state transitions. 150 State Diagram Access the text alternative for slide images. 151 Activity Diagram 2 Access the text alternative for slide images. 152 Swimlane Diagrams The UML swimlane diagram is a useful variation of the activity diagram that allows you to represent the flow of activities described by the use case. Swimlane diagrams indicate which actor (if there are multiple actors involved in a specific use case) or analysis class has responsibility for the action described by an activity rectangle. Responsibilities are represented as parallel segments that divide the diagram vertically, like the lanes in a swimming pool. 153 Swimlane Diagram Access the text alternative for slide images. 154