SE merged).pdf

Chapter 1 Software & Software Engineering Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For no...

Chapter 1 Software & Software Engineering Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1 What is 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 and (3) documentation that describes the operation and use of the programs. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2  What is Software? Soft w are is dev eloped or engineered, it is not manufact ured in t he classical sense. Soft w are doesn't "w ear out." Alt hough t he indust ry is mov ing t ow ard component -based const ruct ion, most soft w are cont inues t o be cust om-built. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3 Wear vs. Deterioration These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4 Software Applications system software application software engineering/scientific software embedded software product-line software WebApps (Web applications) AI software These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5 Software—New Categories Open world computing—pervasive, distributed computing Ubiquitous computing—wireless networks Netsourcing—the Web as a computing engine Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) Also … (see Chapter 31) Data mining Grid computing Cognitive machines Software for nanotechnologies These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6 Legacy Software W hy must it 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. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7 Characteristics of WebApps - I Network intensiveness. A WebApp resides on a network and must serve the needs of a diverse community of clients. Concurrency. A large number of users may access the WebApp at one time. Unpredictable load. The number of users of the WebApp may vary by orders of magnitude from day to day. Performance. If a WebApp user must wait too long (for access, for server-side processing, for client-side formatting and display), he or she may decide to go elsewhere. Availability. Although expectation of 100 percent availability is unreasonable, users of popular WebApps often demand access on a “24/7/365” basis. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8 Characteristics of WebApps - II Data driven. The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end-user. Content sensitive. The quality and aesthetic nature of content remains an important determinant of the quality of a WebApp. Continuous evolution. Unlike conventional application software that evolves over a series of planned, chronologically-spaced releases, Web applications evolve continuously. Immediacy. Although immediacy—the compelling need to get software to market quickly—is a characteristic of many application domains, WebApps often exhibit a time to market that can be a matter of a few days or weeks. Security. Because WebApps are available via network access, it is difficult, if not impossible, to limit the population of end-users who may access the application. Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9 Software Engineering Some realities: a concerted effort should be made to understand the problem before a software solution is developed design becomes a pivotal activity software should exhibit high quality software should be maintainable 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. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 10 Software Engineering 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). These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 11 A Layered Technology tools methods process model a “quality” focus Soft w are Engineering These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 12 A Process Framework Process framew ork Framew ork activities w ork tasks w ork prod u cts m ilestones & d eliverables QA checkpoints Umbrella Activities These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13  Framework Activities Communication Planning Modeling Analysis of requirements Design Construction Code generation Testing Deployment These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 14  Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 15 Adapting a Process Model the overall flow of activities, actions, and tasks and the interd epend encies am ong them the d egree to w hich actions and tasks are d efined w ithin each fram ew ork activity the d egree to w hich w ork prod ucts are id entified and required the m anner w hich quality assurance activities are applied the m anner in w hich project tracking and control activities are applied the overall d egree of d etail and rigor w ith w hich the process is d escribed the d egree to w hich the cu stom er and other stakehold ers are involved w ith the project the level of autonom y given to the softw are team the d egree to w hich team organization and roles are prescribed These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 16 The Essence of Practice Polya suggests: 1. Understand the problem (com m unication and analysis). 2. Plan a solution (m od eling and softw are d esign). 3. Carry out the plan (cod e generation). 4. Examine the result for accuracy (testing and quality assurance). These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 17 Understand the Problem W ho has a stake in the solution to the problem? That is, w ho are the stakehold ers? W hat are the unknowns? What d ata, fu nctions, and featu res are requ ired to properly solve the problem ? Can the problem be compartmentalized? Is it possible to represent sm aller problem s that m ay be easier to u nd erstand ? Can the problem be represented graphically? Can an analysis m od el be created ? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 18 Plan the Solution Have you seen similar problems before? Are there patterns that are recognizable in a potential solu tion? Is there existing softw are that im plem ents the d ata, fu nctions, and featu res that are requ ired ? Has a similar problem been solved? If so, are elem ents of the solu tion reu sable? Can subproblems be defined? If so, are solu tions read ily apparent for the su bproblem s? Can you represent a solution in a manner that leads to effective implementation? Can a d esign m od el be created ? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 19 Carry Out the Plan Does the solution conform to the plan? Is sou rce cod e traceable to the d esign m od el? Is each component part of the solution provably correct? H as the d esign and cod e been review ed , or better, have correctness proofs been applied to algorithm ? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 20 Examine the Result Is it possible to test each component part of the solution? H as a reasonable testing strategy been im plem ented ? Does the solution produce results that conform to the data, functions, and features that are required? H as the softw are been valid ated against all stakehold er requ irem ents? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 21 Hooker’s General Principles 1: The Reason It A ll Exists 2: KISS (Keep It Simple, Stupid!) 3: M aintain the V ision 4: W hat Y ou Produce, Others W ill Consume 5: Be Open to the Future 6: Plan A head for Reuse 7: Think! These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 22  Software Myths 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 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 23 How It all Starts SafeHome: Every softw are project is precipitated by som e bu siness need — the need to correct a d efect in an existing application; the need to the need to ad apt a ‘legacy system’ to a changing business environm ent; the need to extend the functions and features of an existing application, or the need to create a new p rod uct, service, or system. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 24 Chapter 2 Process Models Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1  A Generic Process Model These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 2 Process Flow These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 3 Identifying a Task Set A task set d efines the actu al w ork to be d one to accom plish the objectives of a softw are engineering action. A list of the task to be accom plished A list of the w ork prod u cts to be prod u ced A list of the qu ality assu rance filters to be applied These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4 Process Patterns A process pattern d escribes a process-related problem that is encou ntered d u ring softw are engineering w ork, id entifies the environm ent in w hich the problem has been encou ntered , and su ggests one or m ore proven solu tions to the problem. Stated in m ore general term s, a process pattern provid es you w ith a template [Am b98]—a consistent m ethod for d escribing problem solu tions w ithin the context of the softw are process. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5 Process Pattern Types Stage patterns—d efines a problem associated w ith a fram ew ork activity for the process. Task patterns—d efines a problem associated w ith a softw are engineering action or w ork task and relevant to su ccessfu l softw are engineering practice Phase patterns—d efine the sequ ence of fram ew ork activities that occu r w ith the process, even w hen the overall flow of activities is iterative in natu re. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6 Process Assessment and Improvement 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)—p rovid es a d iagnostic techniqu e for assessing the relative matu rity of a softw are organization; u ses the SEI CMM as the basis for the assessm ent [Du n01] SPICE—The SPICE (ISO/IEC15504) stand ard d efines a set of requ irem ents for softw are p rocess assessm ent. The intent of the stand ard is to assist organizations in d evelop ing an objective evalu ation of the efficacy of any d efined softw are p rocess. [ISO08] ISO 9001:2000 for Softw are—a generic stand ard that ap p lies to any organization that w ants to im p rove the overall qu ality of the p rod u cts, system s, or services that it p rovid es. Therefore, the stand ard is d irectly ap p licable to softw are organizations and com p anies. [Ant06] These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7  Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions … If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8  The Waterfall Model Communicat ion project init iat ion Planning requirement gat hering estimating Modeling scheduling analysis Const ruct ion tracking design Deployment code t est delivery support f eedback These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9 The V-Model These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10 The Incremental Model increment # n Co m m u n i c a t i o n Pla nning M odeling a na ly s i s Co n s t ru c t i o n d es ig n c ode De p l o y m e n t t es t d e l i v e ry fe e dba c k deliv ery of increment # 2 nt h increment Co m m u n i c a t i o n Pla nning M odeling a na l y s i s Co n s t ru c t i o n d es i g n c o de De p l o y m e n t t es t d e l i v e ry fe e dba c k deliv ery of increment # 1 2nd increment Co m m u n i c a t i o n Pla nning M odeling an a l y s i s Co n s t ru c t i o n de s i gn c od e De p l o y m e n t t es t d e l i v e ry deliv ery of fe e dba c k 1st increment project calendar t ime These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11 Evolutionary Models: Prototyping Q u i ck p l an Quick Com m unicat ion plan communication Mo d e l i n g Modeling Q u i ck d e si g n Quick design Deployment Deployment Construction De live r y delivery & of Const prototype r uct ion & Fe e dback feedback Construction of of ot pr prototype ot ype These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12 Evolutionary Models: The Spiral planning estimation scheduling risk analysis communication modeling analysis design start deployment construction delivery code feedback test These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13 Evolutionary Models: Concurrent none Modeling act ivit y represents the state Under of a software engineering activity or task development A wait ing changes Under review Under revision Baselined Done These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14 Still Other Process Models Component based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15 The Unified Process (UP) Elaborat ion elaboration Incept ion inception const r uct ion Release t ransit ion soft ware increment product ion These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16 UP Phases UP Phases Incept ion Elaborat ion Const ruct ion Transit ion Product ion Workflows Requirements Analysis Design Implementation Test Support Iterations #1 #2 #n-1 #n These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17  UP Work Products Incept ion phase Elaborat ion phase Vision document Init ial use-case model Init ial project glossary Const ruct ion phase Use-case model Init ial business case Supplement ary requirement s Init ial risk assessment. including non-funct ional Transit ion phase Design model Project plan, Analy sis model Soft ware component s phases and it erat ions. Soft ware archit ect ure Int egrat ed soft ware Deliv ered soft ware increment Business model, Descript ion. increment Bet a t est report s if necessary. Execut able archit ect ural General user feedback Test plan and procedure One or more prot ot y pes prot ot y pe. I nc e pt i o Test cases n Preliminary design model Support document at ion Rev ised risk list user manuals Project plan including inst allat ion manuals it erat ion plan descript ion of current adapt ed workflows increment milest ones t echnical work product s Preliminary user manual These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18 Personal Software Process (PSP) Planning. This activity isolates requ irements and d evelops both size and resou rce estim ates. In ad d ition, a d efect estim ate (the nu m ber of d efects projected for the w ork) is m ad e. All m etrics are record ed on w orksheets or tem plates. Finally, d evelopm ent tasks are id entified and a project sched u le is created. High-level design. External specifications for each com ponent to be constru cted are d eveloped and a com ponent d esign is created. Prototypes are bu ilt w hen u ncertainty exists. All issu es are record ed and tracked. High-level design review. Form al verification method s (Chapter 21) are applied to u ncover errors in the d esign. Metrics are maintained for all im portant tasks and w ork resu lts. D evelopment. The com ponent level d esign is refined and review ed. Cod e is generated , review ed , com piled , and tested. Metrics are m aintained for all important tasks and w ork resu lts. Postmortem. Using the measu res and m etrics collected (this is a su bstantial am ou nt of d ata that shou ld be analyzed statistically), the effectiveness of the process is d eterm ined. Measu res and m etrics shou ld provid e gu id ance for m od ifying the process to im prove its effectiveness. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 19 Team Software Process (TSP) Bu ild self-d irected team s that plan and track their w ork, establish goals, and ow n their processes and plans. These can be pu re softw are team s or integrated prod u ct team s (IPT) of three to abou t 20 engineers. Show m anagers how to coach and m otivate their team s and how to help them su stain peak perform ance. Accelerate softw are process im provem ent by m aking CMM Level 5 behavior norm al and expected. The Capability Maturity Model (CMM), a measure of the effectiveness of a software process, is discussed in Chapter 30. Provid e im provem ent gu id ance to high -m atu rity organizations. Facilitate u niversity teaching of ind u strial-grad e team skills. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 20 Chapter 3 Agile Development Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 1 The Manifesto for Agile Software Development “We are uncovering better w ays of developing softw are by doing it and helping others do it. Through this w ork w e have come to value: Indiv iduals and int eract ions over processes and tools Working soft w are over comprehensive documentation Cust omer collaborat ion over contract negotiation Responding t o change over follow ing a plan That is, w hile there is value in the items on the right, w e value the items on the left more.” Kent Beck et al These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 2  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 Yielding … Rapid, incremental delivery of software These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3 Agility and the Cost of Change These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 4 An Agile Process Is driven by customer descriptions of what is required (scenarios) Recognizes that plans are short-lived Develops software iteratively with a heavy emphasis on construction activities Delivers multiple ‘software increments’ Adapts as changes occur These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 5 Agility Principles - I 1. Our highest p riority is to satisfy the customer through early and continuous d elivery of valuable softw are. 2. Welcom e changing requirem ents, even late in d evelopm ent. Agile processes harness change for the cu stom er's com petitive ad vantage. 3. Deliver w orking softw are frequently, from a couple of w eeks to a couple of m onths, w ith a preference to the shorter tim escale. 4. Business people and d evelopers m ust w ork together d aily throughout the project. 5. Build projects around m otivated ind ivid uals. Give them the environm ent and support they need , and trust them to get the job d one. 6. The m ost efficient and effective m ethod of conveying inform ation to and w ithin a d evelopm ent team is face–to–face conversation. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 6 Agility Principles - II 7. Working softw are is the prim ary m easu re of progress. 8. Agile processes prom ote su stainable d evelopm ent. The sponsors, d evelopers, and u sers shou ld be able to m aintain a constant pace ind efinitely. 9. Continu ou s attention to technical excellence and good d esign enhances agility. 10. Sim plicity – the art of maxim izing the am ou nt of w ork not d one – is essential. 11. The best architectu res, requ irem ents, and d esigns em erge from self–organizing team s. 12. At regu lar intervals, the team reflects on how to becom e m ore effective, then tu nes and ad ju sts its behavior accord ingly. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 7 Human Factors the process molds to the needs of the people and team, not the other w ay arou nd key traits m u st exist am ong the people on an agile team and the team itself: Competence. Common focus. Collaboration. D ecision-making ability. Fuzzy problem-solving ability. Mutual trust and respect. Self-organization. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 8 Extreme Programming (XP) The most widely used agile process, originally proposed by Kent Beck XP Planning Begins with the creation of “user stories” Agile team assesses each story and assigns a cost Stories are grouped to for a deliverable increment A commitment is made on delivery date After the first increment “project velocity” is used to help define subsequent delivery dates for other increments These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 9 Extreme Programming (XP) XP Design Follows the KIS principle Encourage the use of CRC cards (see Chapter 8) For difficult design problems, suggests the creation of “spike solutions”—a design prototype Encourages “refactoring”—an iterative refinement of the internal program design XP Coding Recommends the construction of a unit test for a store before coding commences Encourages “pair programming” XP Testing All unit tests are executed daily “Acceptance tests” are defined by the customer and excuted to assess customer visible functionality These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 10 Extreme Programming (XP) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 11 Scrum Originally proposed by Schwaber and Beedle Scrum—distinguishing features Development work is partitioned into “packets” Testing and documentation are on-going as the product is constructed Work occurs in “sprints” and is derived from a “backlog” of existing requirements Meetings are very short and sometimes conducted without chairs “demos” are delivered to the customer with the time- box allocated These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 12 Scrum These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 13 Adaptive Software Development Originally proposed by Jim Highsmith ASD — distinguishing features Mission-driven planning Component-based focus Uses “time-boxing” (See Chapter 24) Explicit consideration of risks Emphasizes collaboration for requirements gathering Emphasizes “learning” throughout the process These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 14 Adaptive Software Development These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 15 Dynamic Systems Development Method Promoted by the DSDM Consortium (www.dsdm.org) DSDM—distinguishing features Similar in most respects to XP and/or ASD Nine guiding principles Active user involvement is imperative. DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of deliverables. Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible. Requirements are baselined at a high level Testing is integrated throughout the life-cycle. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 16 Dynamic Systems Development Method DSDM Life Cycle (with permission of the DSDM consortium) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 17 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 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 18 Feature Driven Development Originally proposed by Peter Coad et al FDD—distinguishing features Emphasis is on defining “features” a feature “is a client-valued function that can be implemented in two weeks or less.” Uses a feature template the a(n) A features list is created and “plan by feature” is conducted Design and construction merge in FDD These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 19 Feature Driven Development Reprinted w ith permission of Peter Coad These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 20 Agile Modeling Originally proposed by Scott Ambler Suggests a set of agile modeling principles Model with a purpose Use multiple models Travel light Content is more important than representation Know the models and the tools you use to create them Adapt locally These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 21 Chapter 5 Understanding Requirements Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1  Requirements Engineering-I Inception—ask a set of questions that establish … basic understanding of the problem the people who want a solution the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the customer and the developer Elicitation—elicit requirements from all stakeholders Elaboration—create an analysis model that identifies data, function and behavioral requirements Negotiation—agree on a deliverable system that is realistic for developers and customers These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 2 Requirements Engineering-II Specification—can be any one (or more) of the following: A written document A set of models A formal mathematical A collection of user scenarios (use-cases) A prototype Validation—a review mechanism that looks for errors in content or interpretation areas where clarification may be required missing information inconsistencies (a major problem when large products or systems are engineered) conflicting or unrealistic (unachievable) requirements. Requirements management These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 3 Inception 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? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4 Eliciting Requirements meetings are conducted and attended by both software engineers and customers rules for preparation and participation are established an agenda is suggested a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used the goal is to identify the problem propose elements of the solution negotiate different approaches, and specify a preliminary set of solution requirements These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5 Eliciting Requirements These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6 Quality Function Deployment Function deployment determines the “value” (as perceived by the customer) of each function required of the system Information deployment identifies data objects and events Task deployment examines the behavior of the system Value analysis determines the relative priority of requirements These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7 Elicitation Work Products a statement of need and feasibility. a bounded statement of scope for the system or product. a list of customers, users, and other stakeholders who participated in requirements elicitation a description of the system’s technical environment. a list of requirements (preferably organized by function) and the domain constraints that apply to each. a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. any prototypes developed to better define requirements. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8 Building the Analysis Model Elements of the analysis model Scenario-based elements Functional—processing narratives for software functions Use-case—descriptions of the interaction between an “actor” and the system Class-based elements Implied by scenarios Behavioral elements State diagram Flow-oriented elements Data flow diagram These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9 Use-Cases 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? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10 Use-Case Diagram These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11 Class Diagram From the SafeHome system … These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12 State Diagram Reading Commands State name System status = “ready” Display msg = “enter cmd” Display status = steady State variables Entry/subsystems ready Do: poll user input panel Do: read user input Do: interpret user input State activities These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13 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 also 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. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14 Negotiating Requirements Identify the key stakeholders These are the people who will be involved in the negotiation Determine each of the stakeholders “win conditions” Win conditions are not always obvious Negotiate Work toward a set of requirements that lead to “win- win” These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15 Validating Requirements - I 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? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16  Validating Requirements - II 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 the 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? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17 Chapter 6 Requirements Modeling: Scenarios, Information, and Analysis Classes Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1 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 (called an analyst or modeler in this role) to: elaborate on basic requirements established during earlier requirement engineering tasks build models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 2  A Bridge These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 3 Rules of Thumb The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system. Delay consideration of infrastructure and other non- functional models until design. Minimize coupling throughout the system. Be certain that the analysis model provides value to all stakeholders. Keep the model as simple as it can be. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4 Domain Analysis Softw are d om ain analysis is the id entification, analysis, and specification of com m on requ irem ents from a specific application d om ain, typically for reu se on m u ltiple projects w ithin that application d om ain... [Object-oriented d om ain analysis is] the id entification, analysis, and specification of com m on, reu sable capabilities w ithin a specific application d om ain, in term s of com m on objects, classes, su bassem blies, and fram ew orks... Donald Firesmith These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5 Domain Analysis Define the domain to be investigated. Collect a representative sample of applications in the domain. Analyze each application in the sample. Develop an analysis model for the objects. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6 Elements of Requirements Analysis These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7 Scenario-Based Modeling “[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).” Ivar Jacobson (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? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8 What to Write About? Inception and elicitation—provide you with the information you’ll need to begin writing use cases. Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to identify stakeholders define the scope of the problem specify overall operational goals establish priorities outline all known functional requirements, and describe the things (objects) that will be manipulated by the system. To begin developing a set of use cases, list the functions or activities performed by a specific actor. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9 How Much to Write About? As further conversations with the stakeholders progress, the requirements gathering team develops use cases for each of the functions noted. In general, use cases are written first in an informal narrative fashion. If more formality is required, the same use case is rewritten using a structured format similar to the one proposed. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10 Use-Cases a scenario that describes a “thread of usage” for a system actors represent roles people or devices play as the system functions users can play a number of different roles for a given scenario These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11 Developing a Use-Case What are the main tasks or functions that are performed by the actor? What system information will the 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? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12 Use-Case Diagram These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13 Activity Diagram Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14 Swimlane Diagrams A llows the modeler to represent the flow of activities described by the use-case and at the same time 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 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15 Data Modeling examines data objects independently of processing focuses attention on the data domain creates a model at the customer’s level of abstraction indicates how data objects relate to one another These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16 What is a Data Object? a representation of alm ost any com posite inform ation that m u st be u nd erstood by softw are. composite information— som ething that has a num ber of d ifferent properties or attributes can be an external entity (e.g., anything that prod u ces or consu m es inform ation), a thing (e.g., a report or a d isplay), an occu rrence (e.g., a telephone call) or event (e.g., an alarm ), a role (e.g., salesperson), an organizational u nit (e.g., accou nting d epartm ent), a place (e.g., a w arehou se), or a stru ctu re (e.g., a file). The d escription of the d ata object incorporates the d ata object and all of its attribu tes. A d ata object encapsu lates d ata only—there is no reference w ithin a d ata object to operations that act on the d ata. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17 Data Objects and Attributes A d ata object contains a set of attribu tes that act as an aspect, qu ality, characteristic, or d escriptor of the object object: automobile attributes: make model body type price options code These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18 What is a Relationship? Data objects are connected to one another in different ways. A connection is established between person and car because the two objects are related. A person owns a car A person is insured to drive a car The relationships owns and insured to drive define the relevant connections between person and car. Several instances of a relationship can exist Objects can be related in many different ways These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 19 ERD Notation One common form: (0, m) object1 relationship object 2 (1, 1) attribute Another common form: object1 relationship object 2 (0, m) (1, 1) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 20 Building an ERD Level 1—model all data objects (entities) and their “connections” to one another Level 2—model all entities and relationships Level 3—model all entities, relationships, and the attributes that provide further depth These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 21 The ERD: An Example request Customer places for service (1,1) (1,m) (1,1) standard (1,n) work task table generates order (1,1) (1,1) (1,1) selected work (1,w) from consists (1,w) tasks of (1,i) materials lists These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 22 Class-Based Modeling Class-based m od eling represents: objects that the system w ill m anipu late operations (also called m ethod s or services) that w ill be applied to the objects to effect the m anipu lation relationships (som e hierarchical) betw een the objects collaborations that occu r betw een the classes that are d efined. The elem ents of a class-based m od el inclu d e classes and objects, attribu tes, operations, CRC m od els, collaboration d iagram s and packages. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 23 Identifying Analysis Classes Exam ining the u sage scenarios d eveloped as part of the requ irem ents m od el and perform a "gram m atical parse" [Abb83] Classes are d eterm ined by u nd erlining each nou n or nou n phrase and entering it into a sim ple table. Synonym s shou ld be noted. If the class (nou n) is requ ired to im plem ent a solu tion, then it is part of the solu tion space; otherw ise, if a class is necessary only to d escribe a solu tion, it is part of the problem space. Bu t w hat shou ld w e look for once all of the nou ns have been isolated ? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 24 Manifestations of Analysis Classes A nalysis classes m anifest them selves in one of the follow ing w ays: External entities (e.g., other system s, d evices, p eop le) that p rod u ce or consu m e inform ation Things (e.g, rep orts, d isp lays, letters, signals) that are p art of the information d omain for the p roblem Occurrences or events (e.g., a p rop erty transfer or the com p letion of a series of robot m ovem ents) that occu r w ithin the context of system op eration Roles (e.g., m anager, engineer, salesp erson) p layed by peop le w ho interact w ith the system Organizational units (e.g., d ivision, grou p , team) that are relevant to an ap p lication Places (e.g., m anu factu ring floor or load ing d ock) that establish the context of the p roblem and the overall fu nction Structures (e.g., sensors, fou r-w heeled vehicles, or com p u ters) that d efine a class of objects or related classes of objects These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 25 Potential Classes Retained information. The p otential class w ill be useful d u ring analysis only if inform ation abou t it mu st be rem em bered so that the system can function. N eeded services. The potential class m u st have a set of id entifiable op erations that can change the valu e of its attribu tes in som e w ay. M ultiple attributes. Du ring requ irem ent analysis, the focus shou ld be on "m ajor" inform ation; a class w ith a single attribu te m ay, in fact, be u seful d u ring d esign, bu t is probably better rep resented as an attribu te of another class d u ring the analysis activity. Common attributes. A set of attribu tes can be d efined for the potential class and these attribu tes ap p ly to all instances of the class. Common operations. A set of op erations can be d efined for the p otential class and these op erations ap p ly to all instances of the class. Essential requirements. External entities that ap p ear in the problem sp ace and p rod u ce or consu m e inform ation essential to the op eration of any solu tion for the system w ill alm ost alw ays be d efined as classes in the requ irem ents m od el. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 26 Defining Attributes A ttributes d escribe a class that has been selected for inclu sion in the analysis m od el. bu ild tw o d ifferent classes for professional baseball players For Playing Statistics softw are: name, position, batting average, fielding percentage, years played, and games played m ight be relevant For Pension Fund softw are: average salary, credit toward full vesting, pension plan options chosen, mailing address, and the like. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 27 Defining Operations Do a gram m atical parse of a processing narrative and look at the verbs Operations can be d ivid ed into fou r broad categories: (1) operations that m anipu late d ata in som e w ay (e.g., ad d ing, d eleting, reform atting, selecting) (2) operations that perform a com pu tation (3) operations that inqu ire abou t the state of an object, and (4) operations that m onitor an object for the occu rrence of a controlling event. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 28 CRC Models Class-responsibility-collaborator (CRC) modeling [Wir90] p rovid es a sim ple m eans for id entifying and organizing the classes that are relevant to system or prod u ct requ irem ents. Am bler [Am b95] d escribes CRC m od eling in the follow ing w ay: A CRC m od el is really a collection of stand ard ind ex card s that represent classes. The card s are d ivid ed into three sections. Along the top of the card you w rite the nam e of the class. In the bod y of the card you list the class responsibilities on the left and the collaborators on the right. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 29 CRC Modeling These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 30 Class Types Entity classes, also called model or business classes, are extracted directly from the statement of the problem (e.g., FloorPlan and Sensor). Boundary classes are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. Controller classes manage a “unit of work” [UML03] from start to finish. That is, controller classes can be designed to manage the creation or update of entity objects; the instantiation of boundary objects as they obtain information from entity objects; complex communication between sets of objects; validation of data communicated between objects or between the user and the application. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 31 Responsibilities System intelligence should be distributed across classes to best address the needs of the problem Each responsibility should be stated as generally as possible Information and the behavior related to it should reside within the same class Information about one thing should be localized with a single class, not distributed across multiple classes. Responsibilities should be shared among related classes, when appropriate. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 32 Collaborations Classes fulfill their responsibilities in one of two ways: A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or a class can collaborate with other classes. Collaborations identify relationships between classes Collaborations are identified by determining whether a class can fulfill each responsibility itself three different generic relationships between classes [WIR90]: the is-part-of relationship the has-knowledge-of relationship the depends-upon relationship These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 33 Composite Aggregate Class These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 34 Associations and Dependencies Two analysis classes are often related to one another in some fashion In UML these relationships are called associations Associations can be refined by indicating multiplicity (the term cardinality is used in data modeling In many instances, a client-server relationship exists between two analysis classes. In such cases, a client-class depends on the server- class in some way and a dependency relationship is established These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 35 Multiplicity These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 36 Dependencies These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 37 Analysis Packages Various elements of the analysis model (e.g., use-cases, analysis classes) are categorized in a manner that packages them as a grouping The plus sign preceding the analysis class name in each package indicates that the classes have public visibility and are therefore accessible from other packages. Other symbols can precede an element within a package. A minus sign indicates that an element is hidden from all other packages and a # symbol indicates that an element is accessible only to packages contained within a given package. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 38 Analysis Packages These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 39 Reviewing the CRC Model All participants in the review (of the CRC model) are given a subset of the CRC model index cards. Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate). All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. 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. 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 (or more) of the responsibilities satisfies the use-case requirement. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards. This may include the definition of new classes (and corresponding CRC index cards) or the specification of new or revised responsibilities or collaborations on existing cards. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 40 Chapter 7 Requirements Modeling: Flow, Behavior, Patterns, and WebApps Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use. These