335ExamReview

GUI design: evaluation (lsrra)

1. Some evaluations of a user interface design should be carried out to assess its suitability 2. Ideally, an interface should be evaluated against a usability specification: Learnability: How long does it take a new user to become productive with the system Speed of operation: How well does the system response match the user's work practice Robustness: How tolerant is the system of user error Recoverability: How good is the system at recovering from user errors Adaptability: How closely is the system tied to a single model of work

GUI design: principles

1. User familiarity/User friendly The interface should be based on user-oriented terms and concepts rather than computer concepts. E.g. Read and input data from left to right. 2. Consistency The system should display an appropriate level of consistency. Maintain consistency across a family of applications. Same design rules over multiple interfaces. E.g. Commands and menus should have the same format. 3. User guidance Some user guidance such as help systems, on-line manuals, etc. should be supplied 4. Reduce the user's memory load -Reduce demand on short-term memory of users , e.g. suggestion in search function. 5. Recoverability (forgiveness) The system should provide some functions allow the user to recover from errors. This might include an undo facility, confirmation of destructive actions, 'soft' deletes, etc.

Class diagram (infomational aspect)

1.Class is a description of a group of objects. 2. Key of a class: (example) Video: Video Code (key), Video Name, Type, Year of production. Customer: Customer Code (key), Name, address, date of birth, email address, etc. Rental Rental Number (key), Date, Video names, etc. 3.Common multiplicities are: 0..1 ; 0..n; 1..1 ; 1..n 4.Association Class:an association with their own property 5.Unary association 6.Aggregation association:no existence dependency 7.Composition association: part of the whole 8.Generalisation:A relationship between a generic class (super class) and specialized class (subclass)

DB design

DB design base on class diagram and entity relationship diagram

technical question:

modeling skills analysis module1-1 1-n aggregation, composition, activity diagram.

Agile: Scrum For the SCRUM approach to software development explain the following three terms. Also, sketch a diagram to show their relationship to each other i) Product backlog ii) Sprint iii) Sprint backlog Describe the terms product backlog and sprint in SCRUM approach

- Concepts in Scrum - How it works Scrum—distinguishing features 1.Development work is partitioned into a "produc backlog" 2.Work occurs in "sprints" and is derived from a "backlog" 3.of existing requirements (a collection of stories) 4.Meetings are very short and sometimes conducted without chairs 5. "demos" are delivered to the customer within the time-box allocated 1. SCRUM starts with the Product Backlog which is a prioritized list of all product requirements (user stories) 2. SCRUM teams take on as much of the product backlog as they think they can turn into an increment of product functionality within a 30-day iteration. This is called a Sprint. 3. The team maintains a list of tasks to perform during each Sprint that is called the Sprint Backlog. 4. Multiple teams can take on product increments in parallel, all working from the same Product Backlog. A project will have multiple sprints. 5. Before a sprint starts a meeting is conducted to decide what is going to be developed and delivered in that particular sprint. 6. After the completion of the sprint, a meeting is held to collect feedback from the team. This feedback helps in planning and working on the next sprint. 7. As the development team starts to work on the next sprint, the testing team carries out functional testing of the features developed in the last sprint. 8. This approach gives good results as the testing team works with the developers from the start of the project.

Software Project management: Activities of project manager. Explain the necessity for project scheduling in software project management.

- Planning and scheduling Planning activies 1. The project plan sets out the resources available to the project, the work breakdown and a schedule fo carrying out the work. 2. Define project monitoring mechanisms. 3. Tracking of the progress of the project and compare actual and planned process and costs. 4. The schedule, cost, and risks all have to be revised as the software is developed 5. The project plan is often concerned with the development process. 6. Assess the constraints: Time, budget, staff, tools 7. Define milestone and deliverables. 8. Define project schedule 9. Monitor and control progress. 10. Re-plan project Project scheduling activities 1. Split project into tasks and estimate time and resources required to complete each task. 2. Organise tasks concurrently to make best use of workforce. 3. Minimise task dependencies to avoid delays caused by one task waiting for another to complete. 4. Dependent on project managers intuition and experience. - Activity network 1.Develop activity network (milestone and tasks or task dependency) 2. Identify critical path (the longest path) 3. Adjust milestones to match the deadline 4. Adjust Task by changing/ adding team/persons Critical path: T1, T3,T9,T11,T12. Total 55 days(the longest path)

Software Project management: success criteria

1. Deliver the software to the customer at agreed time 2. Keep overall costs within budget 3. Deliver software that meets customer's expectation 4. Maintain a happy and well functioning development team

7 fundamental concepts in system design (aamhfrr)

1. abstraction—data, procedure, control data abstraction: is a named collection of data that describes a data object procedural abstraction: refers to a sequence of instructions that have a specific and limited function 2. architecture—the overall structure of the software can be represented by Structural models and Functional models. 3. modularity—compartmentalization of data and function Modularity is the single attribute of software that allows a program to be intellectually manageable 4. hiding—is about controlled interfaces. Modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information controlled interfaces: -limits the global impact of local design decisions -emphasizes communication through controlled interfaces -leads to encapsulation—an attribute of high quality design -results in higher quality software 5. functional independence—single-minded function and low coupling Cohesion: The degree to which a module performs one and only one function (relative strength of the module) Coupling: The degree to which a module is connected to other modules in the system (interdependence among modules) 6. refinement— details for all abstractions,reveals low-level details 7. refactoring—a reorganization technique that simplifies the design A reorganization technique that simplifies the design of a component without changing its function and behavior.

V-Model

1.A variation of the waterfall model, it's also called Verification & Validation model as it emphasizes testing at different phases. The testing procedures are developed early in the life cycle before any coding is done, after each phase preceding implementation Verification: checking if the system conforms to its specification (doing things right). Validation: checking if the system meets the user expectations (doing right thing). 2.The model highlights the existence of different levels of testing and depicts the way each relates to a different development phase 3.Once the implementation is finished testing begins, starting from unit testing and moving up one test level at a time until the acceptance testing phase is completed 4. If problems are found during verification and validation, the left side of the V can be re-executed before testing on the right side is re-enacted V-Model Strengths : 1.Simple and easy to manage due to the rigidity of the model 2.Encourages V&V at all phases: each phase has specific deliverables and a review process 3.Higher chance of success over the waterfall model due to the early development of test plans during the life cycle 4. Works well for small projects where requirements are very well understood Weaknesses: 1.No working software is produced until late during the life cycle 2. Not flexible model, adapt to change is expensive 3. Poor model for long and large projects

Prototyping model

1.Allows repeated investigation of the requirements or design 2.Reduces risk and uncertainty in the development 3.Helps with the elicitation and validation of system requirements 4.Can be used to explore particular software solutions and to support user interface design 5.Two models 1. Throw-away prototyping: •The goal of is to ensure that the system requirements are validated and that they are clearly understood. •The throw-away prototype is NOT considered part of the final system. •Time putting together the throw away prototypes is lost unlike the evolutionary approach. 2.Evolutionary Prototyping An approach to system development where an initial prototype is produced and refined through a number of stages to the final system Evolutionary Development 1.Evolutionary Iterative Development enables software engineers to develop increasingly more complex versions of the software 2.Based on the idea of: developing an initial, low-functionality, high-quality implementation for the user. Receiving user comment and refining it through many versions until an adequate system has been developed The software evolves over time (iterations) comunication-> quick plan->design->construction of prototype ->deploy get feedback-> communication... Prototyping advantages 1.Accelerated delivery of the system Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability 2.User engagement with the system the system more likely to meet user requirements, users are more likely to commit to the use of the system Prototyping problems 1.The customer can believe that the prototype is a fully working version of the software, but without realizing the quality or maintainability. They may not be willing to wait for these goals to be achieved in the end 2.The developer will take shortcuts to get the prototype working quickly. Everything may be inappropriate: the OS, the language, the algorithm ... However, they may not undo these decisions later on as they forget why they took them in the beginning

GUI design: interaction styles (dmfcn)

1.Direct manipulation: draw tool e.g. Video Games CAD (ComputerAdd Design) pros: Fast and intuitive, interaction, Easy to learn cons: May be hard to implement Only suitable where there is a visual metaphor for tasks and objects 2.Menu selection e.g. Most general purpose systems pros: Avoid user errors,Little typing required cons: Slow for experienced users, Can become complex if many menu options 3.Form fill-in e.g. Personal loan processing Insurance quote pros: Simple data entry,Easy to learn cons:Take up a lot of screen space 4.Command language e.g. Operating System, Data base manipulation (SQLcommand line) Pros: Powerful and flexible Cons: Hard to learn, Poor error management 5.Natural language can be typed or spoken natural language, e.g. Siri, Information Retrieval-Google e.g. siri, WWW Information retrieval Pros: Accessible to casual users, Easily extended Cons: Require more typing, Natural language processing systems are unreliable

GUI design: before designing

1.Need to take into account: Who the users are What activities are being carried out Where the interaction is taking place (the environment) 2. Optimize the interactions. Make system match the users' activities and needs

Activity Diagram : Swimlane (behavioural aspect)

1.Represents the responsibility of actors/roles within an activity diagram 2. Group activities of the same actor in a swimlane

Architectural design patterns Client-Server pattern (3-tier)

A MusicSpace system is used to sell and distribute music on the internet (such as Music store of iTunes) which allows users to download the music/album or to listen the music online. Each user has an account and they need to top up for their account - prepay- using Paypal or other third party payment service. Users are charged when they listen to the music or download music. Based on the Client-Server 3 tier architecture pattern, present the architecture for that system.

State Transition diagram (behavioural aspect)

A state transition diagram describes objects life cycle,A state of an object is designated by the current values of the object's attributes 1.Object state—object situation in which the object satisfies certain conditions, it can perform relevant actions, or wait for certain events 2. transition—the movement from one state to another 3. event—an occurrence that causes the object to exhibit some predictable form of behavior 4. condition—additional condition to events 5. action—process that occurs as a consequence of making a transition - reaction of object to the event state component: 1.Name describes object state 2. Action on internal event (on event/action): the action is carried out at the time of occurrence of an event which does not lead to another state 3.Do action (do / action ) : recurring or significant action, carried out in the state 4.Entry/Exit action (entry/ action), (exit / action) : action is executed instantly as of entry/exit state

Use Case Model (functional aspect)

Actor(who), Use cases(Verb) and Association(Include, Extend,Generalisation ) Include association: dependency relationship Place order <<include>> Search video Place order<<include>> Send confirmation email Extend association: Specifying an optional dependency relationship between these use cases Place order <<extend >> Log in Use case narratives: 1. Pre-condition (conditions before the use case) 2. Main flows/Basic flows (normal sequence of events for the use case) 3. Alternative flows (some variation or exceptions from basic flow) 4. Post-condition (conditions happensafter the use case) E.g.: Use case Place order Precondition: User must be logged in to the system. Post-condition: An order object is created and a confirmation email was sent out. E.g.:Use case Sign up 1. Main flow: 1. User provides name, a postal address, date of birth, an email address (login account) and a password 2. The system validate the information such as if the email address is valid, the password is valid 3.If the information is validated, a barcode is generated and the customer information is transformed to the card services 4. User registration is finished 2. Alternative flow: 2.1 If the user age is less than 16, the registration is not successful, stop the registration 2.2 If invalid email address, announce invalid email address and repeat Flow 1

Architectural design patterns Client-Server pattern (2-tier)

Client-Server pattern (2-tier) Description: In a client-server architecture, the functionality of the system is organised into services, with each services delivered from a separate server. Clients are users of these services and access servers to make use of them When to use: Used when data in a shared database has to be accessed from a range of locations. Because servers can be replicated, may also be used when the load on a system is variable. Advantages: 1.The principal advantage of this model is that servers can be distributed across a network. 2.General functionality (e.g. a printer service) can be available to all clients and does not need to be implemented by all services. Disadvantages: 1.Each service is a single point of failure so need to deal with service attacks or server failure. 2.Performance depends on the network as well as the system.

Class diagram example

Develop a classes diagram from this functional description: The video store will keep a stock of videotapes, CDs (games and music) and DVD (films, music, and documentary). The inventory is provided by one supplier at the moment, but in the future there will be more suppliers. The store needs to keep track of the supplier of each multimedia item (videotape, CD, DVD) for cases of return/changes. All videotapes and disks are barcoded so that a barcode reader integrated with the system can support the rentals and returns. Each item type has a different renting fee, for instance it is 3€/week for DVD, 1€/week for videotape and 2€/week for a CD.

Functional Requirements vs Non Functional requirements:

Functional requirements set out services the system should provide. Non-functional requirements constrain the system being developed or the development process Functional Requirements: 1. These are statements of services, tasks or functions the system should provide. 2. A functional requirement is usually a "shall statement" Example: 1. A user shall be able to search the appointments lists for all clinics 2. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Non Functional requirements: 1.These are constraints on the services or functions offered by the system such as timing constraints, "look and feel", performance, security, standards, 2.Describe aspects of the system that are not directly related to the functional behaviour of the system. Categories of non functional requirements 1.Usability: define the ease of use of system. 2.Reliability: the frequency of system failure, recovery availability from failure, dependable system 3. Performance: the response time of the system, efficient use of resources 4. Supportability: adaptability, maintainability 5. FURPS+ (Functionality, Usability, reliability, Performance, Supportability) 6. Additional constraints: 6.1. Implementation requirements: Constraint on the implementation of the system, such as use of particular programming languages, hardware platform 6.2. Legal requirements: Concerned with licensing, regulation, and certification issues.

Architectural design patterns A generic layered architecture

Layered architecture pattern Description: Organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system when to use: Used when building new facilities on top of existing systems; when the development is spread across several teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security. Advantages : 1.Allows replacement of entire layers so long as the interface is maintained. 2. Redundant facilities (e.g. authentication) can be provided in each layer to increase the dependability of the system. Disadvantages: 1. Providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather through the layer immediately below it. 2.Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer

Sequence diagram (behavioural aspect)

Online purchase example Create a sequence diagram to model John buying a camera on the Internet. John will connect to some site and search for a camera. He will choose a camera. The system will provide the appropriate searches to make sure that the supplier has the product. John will then be prompted to pay for the camera and provide payment details as well as a delivery address. Once the payment has been cleared by the bank authentication system an email is sent to John and the purchase is complete, otherwise the transaction is refused.

Activity Transition diagram (behavioural aspect)

Represent the flow of logic in object oriented programs/computation (concurrent control and sequential control) Supplement the use-case by providing a diagrammatic representation of procedural flow of action in the execution of a use case Activity diagram contains activities transitions decision points synchronization bars Example of Return DVD use case Flows of events of Return DVDs use case Alternative flows: 2.1 Cannot retrieve any renting for that customer 2.2 Record the case and proceed manually and flag the case to check the cause 2.3 Stop the use case Flow of events of Return DVDs use case Basic flows: 1. Use case start by Staff scanning the member card 2. The system retrieve the renting order 3. Staff scan each DVDs 4. The system retrieve the DVD 5. The system updates DVD status to available 6. The system checks if there is late returns and the corresponding fee 7. User needs to pay for late returns 8. Staff prints out the receipt 9. The use case finishes

Sequence diagram (behavioural aspect)

Sequence Diagrams 1.A sequence diagram is made up of a collection of participants that interact with each other, during the sequence. 2. Where a participant is placed on a sequence diagram is important. 3. Time on a sequence diagram is all about ordering draw: 1.Time on a sequence diagram starts from top to bottom. 2.participants: entity object boundary object :Represents system interface with the actors. e.g. Login page control object: Are responsible for collecting information from the boundary objects e.g. Place order 3.Vertical dash line: participant's life 4.Interaction: occurs when one participant decides to send a message to another participant 5.Activation Bars:When a message is passed to a participant it triggers the receiving participant into doing something. 6. msg: synchronous Msg , has a response (triangle solid arrow, return dash)

Tesing: Static and dynamic testing

Static verification A form of software verification where the software isn't actually used. Generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or documentation. e.g. Design review,Static Code Analysis:Walk-through and Code inspection Dynamic testing: The software must actually be compiled and run to test the physical response from the system. Working with the software, giving input values and checking if the output is as expected by executing specific test cases which can be done manually or with the use of an automated process. Black-box testing: examines the functionality of an application/software under the test without peering into its internal structures or workings White-box testing: tests internal structures or workings of an application, as opposed to its functionality Fault Insertion: Faults are inserted into the source code (or called mutation), and the code is checked to see if it produces a different output.

Analysis phase

System Analysis phase: 1.Object Oriented Analysis 3 aspects: -Informational aspect with data modelling: Class model are used to define the static structure of classes in a system and their associations -Behavioural aspect with behavioural modelling: Activity model (activities) State diagram, (change of state) Sequence model, (interaction) Collaboration diagram Are used to describe the dynamic behavior of an executing system -Functional aspect with scenario based model: Use case model which show the interactions between external actors (users and other systems) with the system in term of intended functions 2.structured Analysis -Data aspect: Entity Relationship (ER) Model -Activities aspect: Data Flow Diagram

Architectural design patterns The Model-View-Controller (MVC)

The Model-View-Controller (MVC) Description: Separates presentation and interaction from the system data. The Model component manages the system data and associated operations on that data. The View component defines and manages how the data is presented to the user. The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model. when to use: Used when there are multiple ways to view and interact with data. Also used when the future requirements for interaction and presentation of data are unknown. Advantages : 1.Allows the data to change independently of its representation and vice versa. 2.Supports presentation of the same data in different ways with changes made in one representation shown in all of them. Disadvantages: 1. Can involve additional code and code complexity when the data model and interactions are simple.

how system architecture affects non functional criteria (pssam)

The non-functional requirements depend on the system architecture- the way in which these components are organised and communicate. 1. performance Localize critical operations and minimize communications. 2. security Use a layered architecture with critical assets in the inner layers. 3. safety Localize safety-critical features in a small number of sub systems. 4. availability Include redundant components and mechanisms for fault tolerance. 5. maintainability Use fine-grain, replaceable components

Maintenance

The process of changing a system after it has been delivered Three different types of software maintenance 1. Fault repair: Fixing coding errors or design errors 2. Environmental adaptation: when there is change in system's environment such as the platform operating system, or other support software 3. Functionality addition: The system requirements change in response to organizational or business change

Tesing: Unit testing, Integration testing, System testing, Acceptance testing

Unit testing: An individual unit of software is tested to ensure that it works correctly. Integration testing: Two or more units are tested to ensure that they intergrated correctly. It can be Top-Down, Bottom-up, or take an 'end-to-end user functionality' approach. System testing The entire software system is tested to make sure that it works correctly and that it meets/solves the user's needs/problem. Acceptance testing The entire software system is tested at the customer environment (field testing or alpha and beta testing) to make sure that it meets the user's needs.

Agile: Advantages

User get software delivered often and fast . embrace changes, user can change thier mind quickly.

Agile: XP Describe the main activities in XP Planning.

What is it ? How it works Extreme programming: An approach to development based on the development and delivery of very small increments of functionality Relies on constant code improvement, and user involvement in the development team XP Planning 1.Begins with the creation of user stories 2.Team assesses each story and assigns a cost (rough estimates of the time to implement each story ) 3.Stories are grouped to for a deliverable increment 4.A commitment is made on delivery date 5.After the first increment project velocity is used to help define subsequent delivery dates for other increments XP Design 1. Encourage the use of CRC (Class Responsibility Collaborator) cards Encourages "refactoring" XP Coding 1. Recommends the construction of a unit test for a story be done before coding commences 2. Encourages "pair programming" 3. As pair programmers complete their work, their code is integrated with the code of others XP Testing 1.Testing is done regularly 2."Acceptance tests" are defined by the customer from user stories and executed to assess customer-visible functionality XP advantages 1.Works best with small to medium size projects 2.Works best for high risk projects where change is likely 3. Works best for experienced, cohesive teams

Use Case Model example :

When the customer returns the DVDs, the correct payment shall be calculated based on renting time, and the status of DVDs must be updated. Details, for example: 2.1 A staff scans the user card 2.2 The system retrieves the renting details 2.3 The staff scans each DVD 2.4 The system retrieves the DVD and updates its status from "rented" to "available" 2.5 The system calculates the fee 2.6 Customer pays fee 2.7 The system prints out the receipt Basic flows: 1. Use case starts by Staff scanning the member card 2. The system retrieves the renting order 3. Staff scans each DVDs 4. The system retrieves the DVD 5. The system updates DVD status to available 6. The system calculates the corresponding fee 7. User needs to pay 8. Staff prints out the receipt 9. The use case finishes Alternative flows: 2.1 Cannot retrieve any renting for that customer 2.2 Record the case and proceed manually and flag the case to check the cause 2.3 Stop the use case 4.1 The DVD is not in the renting list 4.2 Check if the DVD belongs to the store 4.3 Search DVD by title 4.4 If No, proceed manually for that case and flag the case to check the cause 4.5 Stop the use case

State Transition diagram (example)

a state-transition diagram of lift

Incremental Process Models Discuss the emergence of agile methods within the context of iterative and incremental development.

when to use: 1.Used in situations where the initial software requirements are well-defined, but the overall scope of development is not clear yet 2.There may be a need to provide a limited set of software functionality to users quickly, which will be refined in later releases 3. Thus, a process model that produces the software in increments is much more suitable Incremental Development is a practice where the system functionalities are sliced into increments (small portions). In each increment, a slice of functionality is delivered by going through all the activities of the software development process, from the requirements analysis to the deployment. communication->planing->modeling->construction->deploy Incremental Development -Advantages • System functionality is available earlier - first increment satisfies most critical requirements • Early increments act as a prototype to help elicit requirements for later increments • The highest priority system services tend to receive the most testing as they are delivered first • Lower risk of overall project failure Incremental Development - Problems • The process is not visible, costly to measure progress • System structure tends to degrade as new increments are added • It can be difficult to identify common facilities needed by all increments • There is no complete system specification until the final increment is specified. Incremental summary 1.Incremental Development is often used together with the Evolutionary practice of Iterative Development in software development. This is referred to as Iterative and Incremental Development (IID) 2.IDD is the core of the agile methods 2.1 Modern methods recommend 1-6 weeks minimum iteration 2.2 The resulting software from each iteration is a subset of the final system and not just a prototype.

The Waterfall model

• Emphasize planning in early stage, • This model visualizes the software development process as a linear sequence of phases, nonoverlapping phases, Intensive documentation requirements->design->implementation->verification->Maintainance The waterfall model - advantages 1.Simple and easy to manage and implement 2.Good habits. Process visibility 3.Documents are produced at each phase Help to monitor the progress 4.It fits with other engineering process models 5.There is an emphasis on documentation which keeps all knowledge in a central repository and can be referenced easily by new members joining the team The waterfall model - problems • Difficulty of accommodating change • The following phase should not start until the previous phase has finished • Stages overlap and feed information to each other During design, problems with requirements are identified. During coding, design problems are found. • Due to cost of producing and approving documents, iterations are costly and involve significant costly rework • Final product delivered late on in process • Tests are only carried out at the end - this could mean a compromise if time or budgetary constraints exist • Tend to test the system as a whole rather than systematically progressing from Unit testing to System testing • After a small number of iterations it is normal to freeze development; problems are left for later resolution; may mean system won't do exactly what the user wants The waterfall model Suitable within the projects: 1.Requirements are very well documented, clear and fixed (unlikely to change) 2. Product definition is stable 3. Technology is understood and is not dynamic. 4. Ample resources with required expertise are available to support the product. 5. The project is short.