SMA REVIEWER.pdf

SMA Module 3: DATA FLOW DIAGRAMS What is a DFD? Functional Decomposition-single process may need to be -graphical tool that shows how data moves through a system,...

SMA Module 3: DATA FLOW DIAGRAMS What is a DFD? Functional Decomposition-single process may need to be -graphical tool that shows how data moves through a system, broken down into smaller processes. relationship among data flows and how data is stored at a Functional Decomposition / Explosion / Levelling specific location process of creating a hierarchy of DFDs -represents functions or processes which capture, manipulate, a process in the parent DFD is represented in more store, and distribute data between a system and its detail in a child DFD. environment and between components of a system. Any process that cannot be decomposed further is -does NOT intend to provide information about timing, referred to as a primitive process. sequence or synchronization. Step 2: draw the Top-Level Diagram / Level 1-Level 1 is the functional decomposition of Process 0 – shows all the major DFD components/elements processes that comprise the overall system. Shows how the 1.Process Symbol-receives input data and produces output major processes are interrelated by data flows. Shows external that has a different content and/or form. entities and the major processes with which they interact. -presented at various levels of detail or complexity Shows the system-wide data stores used in the system. Depicts -referred to as a black box because the processes from the viewpoint of the organization running it is viewed in terms of its inputs and outputs, the user does the system. Processes are numbered 1, 2, and so on not need to know how it works nor who are involved in the process -Action verb-object 2.External Entity-represents the source of data coming into the system or destination (sink) of data leaving the system -may be a person, organization, unit, device or another application/system Step 3: draw the Lower-level DFDs (level 2) -shows all the 3. Data Store-logical representation of data that the system internal processes that comprise a single process on the top- stores. Data at rest waiting to be used by a process level diagram. If a parent process is decomposed into three (3) child processes, these child processes wholly and completely make up the parent process. Parent process 1 will be decomposed into processes 1.1, 1.2 and 1.3. only non- 4. Data Flow Symbol-Represents one or more data items. The primitive processes need to be decomposed further arrow represents the movement of data Step 4: continue with the decomposition- if further -from external entity to process V.V|from process to process decomposition is needed |from data store to process V.V. Balanced DFDs-The input and output flows in any higher level -label must be noun/adjective-noun DFD (parent DFD) must be maintained in its decomposition or explosion. Notations DFD CONSTRUCTION Step 1: draw a Context Diagram-First DFD in every business process. Shows the context into which the business process fits. Shows the overall business process as just one process Other Guidelines (process 0). The process label does not follow the naming -Always check that DFD is balances convention –it is typically a noun that represents the name of -Process must always have at least one incoming and the process/information system. Shows all the external entities outgoing flow(spontaneous generation, black hole that provide data to or receive information from the system. phenomenon) - X data store – external entity, X external entity-external entity, X data store-data store, X from process to process(recursive data flow) Diverging data flow-splits into multiple flows (A),data may be routed to parallel processes or multiple instances of the same output goes to separate destinations Converging data flow-merges multiple data flows into a single packet for subsequent processing (E) Composite data flow-consists of 2 or more data flows (A and E) Module 4: USE CASE MODEL ex: an image upload that is not actually a receipt may not be Tres Amigos-UML verifiable Ivar Jacobson-Researcher of Soft. Eng. -Some extensions can be triggered at any point in the main James Rumbaugh-Researcher of Human-Comp. Interaction success scenario, uses the * symbol. ex: invoking the help Grady Booch- Soft. Eng facility, receiving a call/SMS/notification while a call is taking UNIFIED MODELING LANGUAGE-products of object-oriented place in a mobile device development that provides a standard set of diagrams used Remarks-includes other information that can’t be provided in to visually represent a system. the main sections of the use case Use Case literature- Alistair Cockburn (“Coburn”) Use Case Diagram- serves as context diagram and graphical Martin Fowler and other practitioners / authors consider his table of contents of all use cases ideas as a primary resource on use case modeling Use Case Model Use Case Narrative-written description of a user’s interaction with the system that’s initiated by the actor example: a person inserts a card in an ATM machine for a bank transaction; the subsequent behavior of the ATM machine may be to reject a card, capture a card, request for an amount, display the balance, etc. Use Case Diagram-high level view of these use cases Use cases may be created for the following purposes: document a business process, capture potential requirements for the purpose of analysis or discussion, define system requirements, model the design of a system Actor-Primary- initiates the use case and interacts with the Use Case Schemes system. Secondary-does not interact with the system on its Casual use case [Cockburn] own but helps in the achievement of the goal. o Title (verb-goal phrase) Includes- relationship between two use cases – the base use o Actor case and the included use case: the base use case o Scope (indicates the system itself; as mentioned above, it incorporates the functionality or behavior of another use case. may be the organization)* Occurs when a set of steps in the main success scenario is o Level (indicates the level of detail – the typical level is user separated into another use case goal)* o Informal description of what happens Casual use case [Fowler] o Title (verb-goal phrase) o Main Success Scenario (numbered list of steps) o Extensions Detailed use case o Title / Name Generalization / Specialization-child use case inherits the o Actor behavior of the parent use case (analogous to the superclass o Preconditions –subclass relationship in programming)child use case may o Trigger have additional behavior of its own o Main success scenario / Basic flow / Basic course of events o Extensions o Postconditions / Results o Notes / Remarks o Author and date o Others (typical additional sections include assumptions, exceptions, recommendations, technical requirements) Extends-relationship between the base use case and an Use Case Sections extending use case. A condition in the base use case triggers Success and failure scenarios the extended behavior -Scenario-specify a specific sequence of actions and interactions between actors and the system Use Case Model = Use Case Diagram + Descriptive Use Cases o [Cockburn] the use case depicts the different ways the goal is accomplished or fails Module 4: PROTOTYPES Main Success Scenario / Basic Flow -concrete model, sample or simulation of a product-exhibits its -main path that the use case will take to reach a successful appearance or basic functionality state; if-then situations are omitted (see extensions) -often used as proof of concept for some idea or design, -takes up to 12 steps, typically numbered means to evaluate and refine the design in terms of look Preconditions-system states expected to be true when use and feel, a means to explore functionality. case begins, when a use case can be triggered even if an In system development- it is a tangible artifact of how a expected system state is not necessarily satisfied, this state system will appear and/or behave must NOT be a precondition, should have been set in the for most systems, this is represented by the user interface- system, not outside of it. ex: admission is outside the enrolment screens or pages with UI elements system – hence it is not a precondition for embedded and IOT devices-more physical versions Triggers-events that initiate a use case ex: a customer phone useful in analysis and design-changes are made based on call that sets the start of a help desk use case; a job order user feedback, may be part of the RA and design process, triggers process order serve as artifacts of RA and design Extensions- represent if-then scenarios in the main/base use users can easily give feedback because it is a concrete case, may be exceptions/error or failure conditions/alternates representation of a system (alternative success scenarios) ex: Enroll Block has 2 alternate paths Confirm Payment - extension 1a is another path to a successful state; the rest are exceptions. always indicate where the use case continues or whether the use case is terminated. If the extension, in whole or in part, consists of too many steps, another use case may be created to represent these multiple steps; the extension will use the name of the new use case instead ex: Enroll Block – extension 4b -indicate only conditions that can be detected by the system Four Aspects/Dimensions THE 3C’s Representation – form that the prototype takes Card-index/story card that contains the story, may be similarly -Paper prototypes-hand-drawn sketches: paper, post-its, sized papers, physical cards-filled out both sides, may include whiteboards, storyboards, video clips: cheap, easy to create details: priority level, estimates, UI, persons involved, remarks throw away, can be annotated Conversations-conversations between users and developers -Electronic prototypes-graphical mock-ups, computer are used to fill in the details of the requirements: meetings, animations simulations that demonstration the effects of user messages, emails, calls Interaction, functional / working prototypes, take more time, Confirmation-acceptance, criteria/ conditions/ tests for the effort and skill to create and revise story to be considered completed. Written at the back of the card. Defined to confirm that the story has been completed Precision/ fidelity – level of detail of the prototype and implanted correctly -low fidelity vs. high fidelity-representation of the prototype Template: context/scenario, action is carried must be adapted to the required precision (paper prototype out, set of observable consequences are expected low fidelity & graphical mock-up- high fidelity) Ex: Given that I am a registered user, When I input my -illustration-details of data elements in a user interface may be username and password, Then I get logged in to the system. incomplete or unorganized-the focus may be the data Other formats: Rule-based or plain English elements present in the UI. The buttons available to the user -may be bulleted list of rules that describe the behavior of the may be the focus, not their locations system. Ex: As a user, I want to have a search field to match a -precision may increase with more iterations name or address in the list of suppliers Acceptance criteria Interactivity – extent to which the user can interact with - A search bar is provided at the top of the list the prototype. A storyboard can simulate the behavior of a - When a value is typed that matches the start of a system when certain buttons are ”clicked”. A video clip or name or address, the search results are shown presentation may not be interactive but can simulate how the Characteristics of a Good Story(INVEST) system functions. May be simulated using static graphical Independent-avoid dependencies between stories, mockups and can be fully interactive. stories- self-contained, can be implemented in any order Negotiable-allows room for negotiation through conversations. Evolution – describes the expected lifecycle of the Notes may be added regarding issues to be resolved during prototype conversations. -Throwaway / Rapid prototypes-created for a purpose and Valuable-write stories in a way that it’s valuable to the thrown away, may be used to determine requirements, customer/end user. Stories should not be written for the validate requirements or determine design options developers. -Iterative prototypes-revised continuously as precision Estimatable-developers must be able to determine the time it increases, details of user interaction are refined as the will take to implement the story. User story must not be too iterations progress, may be more difficult to veer towards large to establish an estimate. If developers lack domain alternative design options knowledge, a conversation should be made. -Evolutionary prototypes-iterative prototypes that eventually Small- a fixed time period is allocated for each iteration in the become the final system, design and implementation are development process. The story may have to be checked as tightly coupled so that the system is built as the prototype to whether it fits within the timebox. Combine or split stories to evolves, requires more planning and deliberation get the right size. The ultimate determination of whether a Some literature –include only throwaway and evolutionary story is appropriately sized is based on the team, its since iteration is an expectation in modeling capabilities, and technologies in use. that a prototype (that has gone through revisions) is going Testable-acceptance criteria must be set-these are used to to be evolutionary is not certain; even advanced test if story meets user requirements. It’s assumed that some prototypes may be discarded for a new one (very costly) form of automation is used in conducting tests. Stories for non- most of the time – developers use a combination of both functional requirements are prone to being not testable -early stages: throwaway Ex -Any user must never wait long for a screen to appear -advanced stages: evolutionary -“wait long” is not specific enough, “A screen should appear within 2 seconds.” Is testable. Strategies and Guidelines User-centered approach-user participation is very beneficial Physical Card Horizontal Prototypes-provide overview of the system so that consistency and coverage are checked. Checks if all requirements are covered. It’s more breadth than depth- requirements are reflected in the prototype but have little interactivity. Typically done during early stages of analysis. Vertical Prototypes-focuses on function/feature that is implemented almost fully to check feasibility. More depth than breadth-more detail/functionality on a specific aspect of the prototype. More technical but not necessarily fully functional Ex: align/move feature of a drawing tool, formatting feature in a word processor. Module 4: USER STORIES Describes feature / functionality of a system from user’s perspective. States who does what and optionally why. Features should be doable within given time period -2-4 weeks Ex. As a 1st year student, I can view my total fees and down payment upon enrolment so that I know how much I need to pay. Writing User Stories Connextra Template(Rachel Davies) -As a , I can/I want to/I need to so that -have- goal(feature/capability) of the user Use Case vs User Story -benefit-(optional) explicit indication of the motivation behind -Use case- one or more scenarios, may correspond to one or the feature more user stories, more detailed. Natural Language-ex: Students can purchase CCA tickets online. Trips can be paid via credit cards.