html5-img
1 / 85

CSCE 431 : Midterm Exam Review

CSCE 431 : Midterm Exam Review. Outline. Software Engineering Software Lifecycle Requirements Configuration Management Object Oriented Design UML Design Patterns. Midterm Exam. Thu 3/6 12:45-2:00pm Covers Introduction through Design Patterns Covers Homeworks 1 and 2

dominy
Download Presentation

CSCE 431 : Midterm Exam Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSCE 431:Midterm Exam Review

  2. Outline • Software Engineering • Software Lifecycle • Requirements • Configuration Management • Object Oriented Design • UML • Design Patterns CSCE 431 Midterm Exam Review

  3. Midterm Exam • Thu 3/6 12:45-2:00pm • Covers Introduction through Design Patterns • Covers Homeworks 1 and 2 • Focus on material covered in slides • Assigned readings are background material to aid your understanding CSCE 431 Midterm Exam Review

  4. Software Engineering • Most large-scale software projects are challenged (over budget, behind schedule, scope reduced) or abandoned • Most “successful” software still has issues CSCE 431 Midterm Exam Review

  5. Five Most Common Causes of Software Project Failure • Unrealistic Schedules • Inappropriate Staffing • Changing Requirements During Development • Poor Quality Work • Believing in Magic CSCE 431 Midterm Exam Review

  6. No Silver Bullet • Claim: no individual technology or practice will yield a 10-fold increase in productivity, reliability, simplicity in 10 years (from 1986) • Further claim: substantial progress will be made over a longer period of time • Both have proven true • Yannis’s Law: “Programmer productivity doubles every 6 years” CSCE 431 Midterm Exam Review

  7. Software Engineering • Bruegge et al Definition: • Software Engineering is a collection of techniques, methodologies and tools that help with the production of a high-quality software system developed with a given budget before given deadline while change occurs. • IEEE Definition: • The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. • The study of approaches as in (1). CSCE 431 Midterm Exam Review

  8. Outline • Software Engineering • Software Lifecycle • Requirements • Configuration Management • Object Oriented Design • UML • Design Patterns CSCE 431 Midterm Exam Review

  9. Software Lifecycle • Life of software from idea to deployed and maintained application CSCE 431 Midterm Exam Review

  10. Software Development Process • No-Method Process • Sketch, code, debug, modify, repeat • Waterfall Model • Requirements  Design  Implementation  Verification Maintenance • Sequential, inflexible, lots of documentation • Can include some feedback • Assumes requirements are complete • V-Model Model • Testing a parallel activity to development CSCE 431 Midterm Exam Review

  11. SW Development Process (2) • Evolutionary Model • Prototype, evaluate, then build • Prototype Model • Prototype, evaluate, repeat until convergence • Spiral Model • Iterate through waterfall model – 6-24 months • Generate succession of prototypes/versions • Continuous assessment of risk • Most successful approach for safety-critical systems CSCE 431 Midterm Exam Review

  12. SW Development Process (3) • Agile • Focus on schedule • Frequent cycles of code, build, test • Every build integrated all code from the cycle • Stable, deliverable, partially-complete system • Features • Refactoring • Continuous integration • Pair programming • Shared code • Coding standard • Common work space • Customer as part of team • Driven by user stories CSCE 431 Midterm Exam Review

  13. SW Development Process (4) • More Agile features • Assume requirements specs will change during project - ~50% of requirements done when project starts • But only change specs between development cycles • Documents and code evolve together • Document with diagrams, e.g. UML • Agile manifesto • Individuals and interactions >> processes and tools • Working SW >> comprehensive documentation • Customer collaboration >> contract negotiations • Responding to change >> following a plan CSCE 431 Midterm Exam Review

  14. SW Process Maturity • Capability Maturity Model (CMM) • Initial Level • Also called ad hoc or chaotic, may require “heros” • Repeatable Level • Process at least documented • Defined Level • Process is institutionalized (sanctioned by management) • Managed Level • Quantitative, agreed upon metrics, provide feedback for resource allocation (process itself does not change) • Optimizing Level • Process allows feedback of information to change the process itself CSCE 431 Midterm Exam Review

  15. Outline • Software Engineering • Software Lifecycle • Requirements • Configuration Management • Object Oriented Design • UML • Design Patterns CSCE 431 Midterm Exam Review

  16. Requirements • Large fraction of SW system problems due to incomplete/wrong requirements • Requirement are statements of desired behavior for a system • Requirements process has two activities: • Requirements elicitation — definition of the system in terms understood by the customer and/or user • Requirements analysis — definition of the system in terms understood by the developer CSCE 431 Midterm Exam Review

  17. Requirements Goals • Understand the problem or problems that the eventual software system, if any, should solve • Prompt relevant questions about the problem and system • Provide basis for answering questions about specific properties of the problem and system • Decide what the system should do • Decide what the system should not do • Ascertain that the system will satisfy needs of its stakeholders • Provide basis for development of the system • Provide basis for validation and verification (especially testing) of the system CSCE 431 Midterm Exam Review

  18. Requirements Components • Domain properties • Assumptions that are true in the domain • Functional requirements • Non-functional requirements • Reliability • Security • Accuracy of results • Time and space performance • Portability • … CSCE 431 Midterm Exam Review

  19. Roles of Domain Properties vs. Requirements • Requirement R: • “The database shall only be accessible to authorized personnel” • Domain Properties D: • Authorized personnel have passwords • Passwords are never shared with non-authorized personnel • Specification S: • Access to the database shall only be granted after the user enters an authorized password • S, DR • But what if domain assumptions are wrong? CSCE 431 Midterm Exam Review

  20. Quality Goals for Requirements • Correct • Complete • Consistent • Unambiguous • Traceable • Modifiable • Verifiable • Prioritized 830-1998 — IEEE Recommended Practice for Software Requirements Specifications CSCE 431 Midterm Exam Review

  21. A Balancing Act • One should not over-specify • == committing too early to a specific implementation • One should not under-specify • == leaving some parts of the problem missing CSCE 431 Midterm Exam Review

  22. Requirements Example • Study Naur’s example • B. Meyer definition of specification: • Precise definition of the tasks to be performed by the system • Requirements are a natural-language definition of the system objectives • Favor precise, falsifiable language over pleasant generalities! CSCE 431 Midterm Exam Review

  23. Seven Sins of Specifier • Noise • Irrelevant information, redundancy, remorse (restriction at use, not definition, of an element) • Silence • Feature exists, but not discussed • Over-specification • Specification of a solution to the problem, not the problem • Contradiction • Ambiguity • Forward reference • Wishful thinking • Feature definition, for which candidate solutions cannot be realistically validated CSCE 431 Midterm Exam Review

  24. Complete Requirements • Definition from IEEE standard: An SRS (Software Requirements Specification) is complete if, and only if, it includes the following elements: • All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated. • Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values. • Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure. CSCE 431 Midterm Exam Review

  25. SRS Structure 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms, and abbreviations Glossary 1.4. References 1.5. Overview 2. Overall description 2.1. Product perspective 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5. Assumptions and dependencies 3. Specific requirements Appendices Index CSCE 431 Midterm Exam Review

  26. Requirements and Agile Methods • Under XP (Extreme Programming) • Requirements are taken into account as defined at the particular time considered • Requirements are largely embedded in test cases • Benefits • Test plan will be directly available • Customer involvement • Risks • Change may be difficult (refactoring) • Structure may not be right • Tests only cover the foreseen cases • Possibly useful advise • Retain the best agile practices, in particular frequent iterations, customer involvement, centrality of code and testing • Disregard those that contradict proven SE principles CSCE 431 Midterm Exam Review

  27. Techniques for Requirements Elicitation • Questionnaires: Asking the end user a list of pre-selected questions • Task Analysis: Observing end users in their operational environment • Scenarios: Describe the use of the system as a series of interactions between a specific end user and the system • Use Cases: Abstractions that describe a class of scenarios CSCE 431 Midterm Exam Review

  28. Techniques for Requirements Elicitation • Questionnaires: Asking the end user a list of pre-selected questions • Task Analysis: Observing end users in their operational environment • Scenarios: Describe the use of the system as a series of interactions between a specific end user and the system • Use Cases: Abstractions that describe a class of scenarios CSCE 431 Midterm Exam Review

  29. Use Cases • The system treated as a “black box” (== the interactions with system, including system responses, are as perceived from outside the system) • Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals • Acomplete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system. • Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain • With some help from graphical notations, such as UML use case and sequence diagrams CSCE 431 Midterm Exam Review

  30. What is UML? • UML == Unified Modeling Language • Nonproprietary standard for modeling software systems, OMG • Convergence of notations used in object-oriented methods • OMT (Object Modeling Technique, James Rumbaugh and colleagues) • Booch (Grady Booch) • OOSE (Ivar Jacobson) • Current Version: UML 2.3 (May 2010) • Information at the OMG portal http://www.uml.org • Commercial tools: • Rational (IBM), Together (Borland), Visual Architect (business processes, BCD) • Open Source tools: • ArgoUML, BOUML, Dia,… CSCE 431 Midterm Exam Review

  31. UML Diagrams CSCE 431 Midterm Exam Review

  32. UML Diagrams • Use case diagrams • Describe the functional behavior of the system as seen by the user • Class diagrams • Describe the static structure of the system: Objects, attributes, associations • Sequence diagrams • Describe the dynamic behavior between objects of the system • Statechart diagrams • Describe the dynamic behavior of an individual object • Activity diagrams • Describe the dynamic behavior of a system, in particular the workflow CSCE 431 Midterm Exam Review

  33. Summary of Requirements • Goal: SRS that describe the problem, not solution • Variety of sources and means for eliciting requirements • Use what makes most sense in the situation • Variety of definition and specification techniques • Use what makes most sense in the situation • Requirements should be validated (that they meet customer expectations) • Specifications should be verified (that they satisfy requirements) CSCE 431 Midterm Exam Review

  34. Outline • Software Engineering • Software Lifecycle • Requirements • Configuration Management • Object Oriented Design • UML • Design Patterns CSCE 431 Midterm Exam Review

  35. Software Configuration Management (SCM) Software configuration management goals: • Configuration identification - identify configurations, configuration items and baselines • Configuration control - implement controlled change process; e.g. change control board to approve/reject change requests against a baseline • Configuration status accounting – record/report all necessary information on status of development process • Configuration auditing – ensure configurations contain all intended parts and are sound w.r.t. specifying documents, including requirements, architectural specs and user manuals • Build management – manage process and tools used for system builds • Process management - ensure adherence to development process • Environment management – manage HW/SW that hosts the system • Teamwork – facilitate team interactions related to the process • Defect tracking – make sure every defect has traceability back to the source http://en.wikipedia.org/wiki/Software_configuration_management CSCE 431 Midterm Exam Review

  36. Why Separate Branches? • Separation of concerns • Less contention over the repository • Groups commit according to common theme, allowing easier porting or roll-back CSCE 431 Midterm Exam Review

  37. Possible Branches • Examples • Released versions • Soon-to-be-released versions • Ongoing development • Ideas may never show up in a release, but you never know, so don’t flush the code • Features or topics • Hotfixes • Branch models are generally portable among version control systems CSCE 431 Midterm Exam Review

  38. Branch Model CSCE 431 Midterm Exam Review

  39. Main Branches • “master” • Each commit is tagged with a version number • Released versions of the product are built from this branch • “develop” • Latest set of features that will go into the next release • Always left in a functioning state (no work in progress) • These branches live forever • Other supporting branches have limited lifetimes CSCE 431 Midterm Exam Review

  40. Release Branches • “release-*” • Whenever the “develop“ branch is feature-complete for the next release, create a release branch off of “develop“ • Only bugfixes or new metadata (like version numbers) may be committed • This branch may periodically be merged into “develop“ to pass on the bugfixes • When the release is complete: • Merge it into “master“ and tag • Merge it into “develop“ one last time • Delete it CSCE 431 Midterm Exam Review

  41. Feature Branches • “*” (any unique name) • Whenever a developer wants to begin work on a new feature, bugfix, refactoring,… create a feature branch off of “develop“ • Try to break commits into their smallest, independent units • When the feature is complete and will be included in the next release: • Merge it into “develop“ • Delete it CSCE 431 Midterm Exam Review

  42. Hotfix Branches • “hotfix-*” • Sometimes we make mistakes • Whenever we need an urgent fix for a released version, create a hotfix branch off of “master“ • Treat it exactly like an unplanned release branch • When a hotfix is complete: • Merge it into “master“ and tag • Merge it into “develop“ • Delete it • This model only supports hotfixes for the latest release • If you want to support old versions after new ones have been released, then do not delete release branches CSCE 431 Midterm Exam Review

  43. Branch Model CSCE 431 Midterm Exam Review

  44. Configuration Management Summary • Typical code development has graph-like dependencies • Use version control systems to manage code • Permits synchronization and consistency across developers • Permits roll back to previous point in code history CSCE 431 Midterm Exam Review

  45. Outline • Software Engineering • Software Lifecycle • Requirements • Configuration Management • Object Oriented Design • UML • Design Patterns CSCE 431 Midterm Exam Review

  46. From Requirements to Design • S, DR • S= specification • D = domain properties • R = requirements • Come up with a design that satisfies S CSCE 431 Midterm Exam Review

  47. Role of Object-Oriented Analysis • Analysis object model later refines to object model • Analysis object and dynamic models basis of system design CSCE 431 Midterm Exam Review

  48. Analysis • Developers formalize requirements specification • Examine exceptional cases, boundary conditions • Clients engaged • OO Analysis • Developers build an object model of the application domain • Extend model with how actors and system interact with the application domain objects CSCE 431 Midterm Exam Review

  49. Basic Process of Class Design • Iterate in some order, until convergence • Identify classes • Find attributes • Find operations • Find associations between classes • Above too vague • Some guidance exists CSCE 431 Midterm Exam Review

  50. Different Kinds of Objects • Often the following categories can be identified • Suggested in: Jacobson, Booch, Rumbaugh: The Unified Software Development Process. Addison-Wesley, 1999 • Entity objects • Represent the persistent information tracked by the system • Application domain objects, also called “Business objects” • Boundary objects • Represent the interaction between the user and the system • Control objects • Represent the control tasks performed by the system • Somewhat related to a model-view-controller architecture CSCE 431 Midterm Exam Review

More Related