欢迎来到麦多课文档分享! | 帮助中心 海量文档,免费浏览,给你所需,享你所想!
麦多课文档分享
全部分类
  • 标准规范>
  • 教学课件>
  • 考试资料>
  • 办公文档>
  • 学术论文>
  • 行业资料>
  • 易语言源码>
  • ImageVerifierCode 换一换
    首页 麦多课文档分享 > 资源分类 > PPT文档下载
    分享到微信 分享到微博 分享到QQ空间

    Lecture 3 Software Process Models - Requirements Analysis.ppt

    • 资源ID:372966       资源大小:377KB        全文页数:42页
    • 资源格式: PPT        下载积分:2000积分
    快捷下载 游客一键下载
    账号登录下载
    微信登录下载
    二维码
    微信扫一扫登录
    下载资源需要2000积分(如需开发票,请勿充值!)
    邮箱/手机:
    温馨提示:
    如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
    如需开发票,请勿充值!如填写123,账号就是123,密码也是123。
    支付方式: 支付宝扫码支付    微信扫码支付   
    验证码:   换一换

    加入VIP,交流精品资源
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    Lecture 3 Software Process Models - Requirements Analysis.ppt

    1、Lecture 3 Software Process Models / Requirements Analysis,Topics Mythical Man Month Waterfall model Spiral Method Requirements Analysis Readings: Chapter 3,January 15, 2009,CSCE 492 Software Engineering,Overview,Last Time Overview Quality Software Todays Lecture Pragmatics UML references, Teams Mode

    2、ls for the process of software development Waterfall model, Spiral model, Agile, Requirements References: Chapters 2 and 3 of the text Boehm paper “Spiral Model” Next Time:,UML Unified Modeling Language,UML reference http:/ Website of Quickreference Cards http:/www.digilife.be/quickreferences/quickr

    3、efs.htm,Teams,Team 1: BENDER SAMUEL, BENNETT RONALD, BUSH BRANDON, SCHANDLER J M, CHILDERS WESLEY Team 2: CROCKETT MATTHEW, DINKINS CHANCE, ELLIOTT MICHAEL, GALLOWAY SCOTT, HITE E Team 3: MICHALSKI JASEN, RABON TONI ANN, SHANNON MARION, SIMMONS KATIA, STIFFLER N Team 4: STOICHITA RAZVAN, TAYLOR KARE

    4、EM, THAPA BIJAYA, VAN OLINDA M,Working in Teams,Be conscientious about due dates Meet regularly with your team Always create an agenda for every team meeting Rotate responsibility for chairing team meetings,Authors slide modified,Holding Effective Team Meetings,Create a clear agenda addressing the e

    5、ssential tasks that must be accomplished in order to complete the necessary deliverables Stick to the agenda during the meeting Ensure that each team member understands his or her tasks before the meeting is adjourned Ensure that tasks are equitably distributed,Authors slide modified,Class Project D

    6、eliverables,The deliverables associated with the class project are essential to successfully completing the project The class project is not merely a programming assignment The deliverables result from completing tasks associated with analysis, design, implementation, and testing the class project,A

    7、uthors slide modified,General Project Parameters,Type 1 Projects: Web-enabled System Web interface Database backend Publically accessible Security/permissions issues Examples: appointment calendar, scheduling system Type 2 Projects: Stand-alone Systems More elaborate graphics May require a database

    8、Examples: games, mobile data collection tool Suggestions from the floor?,Should we fix this bug or not?,Four questions when a bug is discovered (Severity) When this bug happens, how bad is the impact? (Frequency) How often does this bug happen? (Cost) How much effort would be required to fix this bu

    9、g? (Risk) What is the risk of fixing this bug?,http:/ and Frequency,The vertical axis is Severity. The top of the graph represents a bug with extremely severe impact: “This bug causes the users computer to burst into flame.“ The bottom of the graph represents a bug with extremely low impact: “One of

    10、 the pixels on the splash screen is the wrong shade of gray.“ The horizontal axis is Frequency. The right side represents a bug which happens extremely often: “Every user sees this bug every day.“ The left side represents a bug which happens extremely seldom: “This bug only affects people who live i

    11、n eastern Washington state and who have both Visual Studio 2003 and Visual Studio 2005 installed and it only happens during leap years on the day that daylight savings time goes into effect and only if the first day of that month was a Tuesday.“,http:/ Man-Month,Main Ideas in “Mythical Man-Month” co

    12、llection of essays Mythical Man-Month Second-system effect IBM 7094360, the second system an engineer designs will be too ambitious, including way too much Progress Tracking Question: How does a large software project get to be one year late? Answer: One day at a time! Conceptual Integrity The Pilot

    13、 System Communication http:/en.wikipedia.org/wiki/The_Mythical_Man-Month,Waterfall Model of Software Life Cycle,Not the first iterative method But the first paper to explain why to use the iterative method,Figure from Barry Boehm88,Water Fall Model,Requirements analysis Design Implementation Testing

    14、 (validation) Integration maintenanceReference http:/en.wikipedia.org/wiki/Waterfall_process,The Spiral Model,Note iterative repetition of the cycle!,Requirements Analysis,Software requirements analysis is the activity of eliciting, analyzing, and recording requirements for software systems. 1 Elici

    15、ting Requirements 2 Analyzing Requirements 3 Recording Requirements,Requirements Analysis,A requirement is a feature of the system Requirements analysis seeks to assess and specify the behavior of the final system Requirements analysis can be iteratively carried out or done in a top-down fashion It

    16、is desirable to establish the breadth of behavior of a system to determine the primary classes that will comprise the systemReference: Most requirements analysis slides are from authors,The Importance of Requirements Analysis,Frederick Brooks: “The hardest single part of building a software system i

    17、s deciding precisely what to build” Barry Boehm: by investing more up-front effort in verifying and validating the software requirements, software developers will see reduced integration and test costs, as well as higher software reliability and maintainability,Examples of Good Requirements Analysis

    18、,Participatory analysis Involves staff members of all levels from the domain area interacting directly with the development team Negotiation-based technique Developed by USC Center for Software Engineering Collaborative analysis approach involving end-users,Requirements Specification,Requirements an

    19、alysis results in a complete, consistent, correct, and unambiguous requirements specification The initial specification may be created by the end users or by the technical staff Independent of the source of the initial specification it must be refined and verified to be correct and complete,Possible

    20、 Elements of Requirements Specification,Supported activity list Human-computer interface description solved problem list Information source list Information requesting organization list Checks and balances Security and fault-tolerant requirements,More: Possible Elements of Requirements Specification

    21、,Inter-operating systems list Estimates of present information capacity and projected growth Project time frame Prioritization of requirements Ethical concerns list,Case Study: Library Management System,Independent of who creates the requirements specification (end users or technical staff), it is t

    22、he responsibility of the system developers to ensure the user requirements are adequately fleshed out The first step of requirements analysis is to establish and refine the problem statement which takes the form of the requirements specification,LMS Case Study: Clarifying the Requirements Specificat

    23、ion,What sort of human-computer interface is envisioned?What sort of search facility is necessary for library patrons?Will patrons be assigned a unique ID number?Should the system support inter-library loan requests?,LMS Case Study: More Clarifying the Requirements Specification,Are there any limits

    24、 on patrons use of research databases?How are books retired from the library collection?How long are requested books held for patrons?Are overdue fees the same for all type of library resources?Which online databases will the system interact with?,Creating Quality Requirements Specifications,The key

    25、 is to keep in close communication with the end users throughout the development process, but especially during requirements analysisIdeally, a whole array of different end users should be involved with the development team to gain sufficient breadth of input,LMS Case Study: Supported Activity List,

    26、Support Library staff activities like checking out resources to patronsValidating patrons Current membership No resources more than two weeks overdue Not over maximum of checked resourcesAssigning library numbers to patrons,LMS Case Study: More Supported Activity List,Deleting expired library number

    27、s and associated patron records Checking out library resources: books,CDs, etc Checking in library resources Changing the status of a library resource Allowing materials to be placed on reserve Allowing the searching of the librarys holdings on line Additional activities listed in text,Other Element

    28、s of the LMS Requirements Specification,Human-computer interface Solved problems list Information source list Information requesting organizations Automated checks and balances Security and fault-tolerant requirements Present information capacity and projected growth,More Elements of the LMS Require

    29、ments Specification,Projected time frame Prioritization of requirements Ethical concerns Who has access of borrowing history of patrons? How are children protected from questionable materials found on the Internet?,Verifying Requirements,A structured walkthrough with the end users is a good techniqu

    30、e for ensuring that the user needs are being addressed To ensure that the resulting software supports the requirements specification, items on the supported activity list are numbered and propagated through the software models and source code,The Process of Requirements Analysis,Create verified requ

    31、irements specification Create list of primary classes Create informal scenarios Create use cases Create scenarios Create class diagrams Create use case diagrams,Identifying Use Cases,A use case is a description of a scenario (or closely related set of scenarios) in which the system interacts with us

    32、ers of the system The behavior of the system is expressed without specifying how the behavior is implemented Use cases are initially described narratively, and then modeled graphically by class diagrams and interaction diagrams (to be discuss later) Informal scenarios are a good starting point for u

    33、se cases,Characteristics of Use Cases,Use cases are more abstract than informal scenarios A single use case may encompass multiple scenarios Use cases avoid redundancy Use cases are more formally structured than scenarios Use cases seek to capture complete breadth of system behavior,Use Case Layout,

    34、Precondition What conditions must be true at the beginning of the use case? Main flow of events Describe the essential behavior associated with the use case Post condition What occurs as a result of the use case executing Exceptional flow of events ( zero to many) Enumerate possible erroneous flow o

    35、f events,LMS Case Study: Use Cases,Validate patron Check out resource Check in resource Request resource Reserve resource Manage Resource Manage Patron Generate from letter,LMS Case Study: Check out Resource Use Case,PreconditionLibrary staff and patron validated to LMS Library DB initialized Main f

    36、low of events Enter resource Determine due date Exceptional flow of events Patron ID not valid Patron has over due resources or too many checked Resource number not valid,More LMS Case Study: Check out Resource Use Case,Postcondition Patron DB entry updated to reflect new resource Resource DB entry

    37、updated to reflect changed status: checked out Due date assigned to the resource DB entry,Scenario Development,Scenarios are derived from use cases Scenarios are like informal scenarios, but are more formally structured Informal scenarios may be modified to produce scenarios Use cases are abstract b

    38、ecause they do not reference specific values Scenarios are concrete because they do reference specific values Multiple scenarios may be required for a single use case,UML Use Case Diagrams,Use case diagrams depict use cases interacting with external actors External actors are entities that interact

    39、with the software system, like system users, databases, or books Use cases represent system requirements and show a functional partitioning of the system Functional partitioning is useful for a dividing a system into smaller pieces,Notational Elements of Use Case Diagrams,Use case name,Actor,Use cas

    40、e,Relationships:,Dependency,Association,Generalization,LMS Case Study: Use Case Diagram,Browse Resource,Request Resource,Reserve Resource,Patron,Resource,Steps in UCCD Analysis Process,Create/refine requirements specification Create informal scenarios Create list of primary classes Create use cases Create scenarios from use cases Create class diagrams showing basic inter-class relationships Model key class collaborations Create use case diagrams,


    注意事项

    本文(Lecture 3 Software Process Models - Requirements Analysis.ppt)为本站会员(ideacase155)主动上传,麦多课文档分享仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文档分享(点击联系客服),我们立即给予删除!




    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
    备案/许可证编号:苏ICP备17064731号-1 

    收起
    展开