Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
COSC 412 Midterm
| Term | Definition |
|---|---|
| Software is | 1. Instructions 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 programs |
| Is software "manufactured" in the classical sense? | No |
| Does software wear out? | No |
| Software Engineering (IEEE Definition) | 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) |
| Does software have spare parts? | No |
| Changing nature of software as mobile apps | 1. Provide persistent storage within the platform 2. A mobile app can gain direct access to hardware found on the device to provide local processing and capabilities (ex. camera or GPS) |
| Security problems within mobile apps | Can steal logs, record audio without user knowledge |
| Cloud computing | 1. Provides distributed data storage and processing resources to networked computing devices |
| What type of architecture does cloud computing require? | Frontend and backend services |
| Product line software | 1. A set of software-intensive systems that share a common set of features and satisfy the needs of a particular market 2. Developed using the same application and data architectures using a common core of reusable software components |
| A software product line... | Shares a set of assets that include requirements, architecture, design patterns, reusable components, test cases, and other work products |
| What is any software approach built on? | A commitment to quality. The purpose of approaches is to increase quality and decrease bugs |
| What is a software process? | A collection of activities, actions, and tasks |
| True or False: a process is a rigid prescription for building software | False |
| A process framework includes... | 1. Framework activities 2. Umbrella activities |
| Framework activities | 1. Communication 2. Planning 3. Modeling 4. Construction 5. Deployment |
| Umbrella activities | Applied throughout the software development process, helps a team manage and control progress, quality, change, and risk |
| True or False: a process for project A might be significantly different from a process of project B | True |
| Process flow | Describes how the framework activities and the actions and tasks that occur within each framework activity are organized |
| Process model | 1. Provides specific roadmap for software engineering work 2. Defines the flow of all activities, actions, tasks, the degree of iteration, the work products, the organization of the work |
| Waterfall Model | 1. When requirements for a problem are well-understood 2. When well-defined adaptations or enhancements must be made 3. When requirements are well-defined and reasonable stable |
| V-Model | LOOK AT SLIDE 32 IN MIDTERM REVIEW YA DINGUS!!!!!! |
| Problems of Waterfall Model | 1. A customer must have patience. A working version will not be available until late in the project time span. A major blunder can be disastrous 2. Linear nature of classic life cycle leads to "blocking states" |
| Incremental model: what if... | 1. Initial software requirements are well-defined... 2. But the overall scope of the development effort precludes a purely linear process 3. Need to provide limited set of software functionality to users quickly, then refine and expand |
| What is the first increment in the incremental model? | The core product |
| Evolutionary process model | 1. Explicitly designed to accommodate a product that grows and changes 2. Iterative 3. Enables development of more complete versions of software |
| Prototype | Ideally serves as a mechanism for identifying software requirements |
| Problems with prototyping | 1. Stakeholders see a working version 2. Stakeholders ask to fix prototypes instead of rebuilding a high-quality system 3. Software engineers often make implementation compromises just for getting a prototype working quickly |
| Spiral model | Evolutionary process model that couples iterative nature of prototyping with the controlled and systematic aspects of the waterfall model |
| Advantage of spiral model | High amount of risk analysis |
| Disadvantages of spiral model | Risk analysis requires highly specific expertise, doesn't work well for small or low-risk projects |
| Agile process model | Iterative approach focusing on code, not design |
| Agile software development manifesto | Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan |
| CRC Cards | 1. Class 2. Responsibilities 3. Collaborators |
| Examples of refactoring | 1. Reorganization of class hierarchy 2. Tidying up and renaming attributes and methods to make them easier to understand 3. Replacement of inline code with calls to methods that have been included in program library |
| True or False: Refactoring changes external behaviors | False |
| Pair programming roles | 1. Driver: writes code 2. Observer/navigator: reviews each line of code as it is typed in |
| Three artifacts of scrum | 1. Product backlog 2. Sprint backlog 3. Burndown chart |
| Product backlog | List of work to be done on the project |
| Sprint backlog | List of work to be done on the current sprint, includes set of user stories |
| User story example (front of card) | As a student I want to purchase a parking pass so that I can drive to school Priority: Should |
| User story example (back of card) | Confirmations: -One pass for one month issued at a time Person buying pass must be currently enrolled student -Student may only buy one pass per month |
| MoSCoW | Must Should Could Won't |
| Must | User stories must be implemented |
| Should | User stories that would ideally be implemented |
| Could | User stories that would be nice to have implemented |
| Won't | User stories that are not needed within the current release |
| Daily scrum meet questions | 1. What did I do yesterday? 2. What will I do today? 3. What challenges did I face? |
| Scrum benefits | -Product broken down into set of manageable and understandable chunks -Improved communication -On-time delivery of increments -Trust between customers and developers established |
| Agile method applicability | Product development where a software company is developing a small or medium-sized product for sale |
| Types of requirements | 1. User requirements 2. System requirements |
| User requirements | Statements in natural language plus diagrams of the services the system provides and its written operational constraints |
| System requirements | Structured document detailing description of system's functions, services, and operational constraints |
| Functional requirements | Statement of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations |
| Non-functional requirements | Constraints on the services or functions offered by the system such as timing constraints, constraints on development process, standards, etc. |
| Are non-function requirements more critical than functional requirements? | Arguably, yes. If non-functional requirements are not met, the system is useless. May be more difficult to state precisely early on, verify |
| Examples of non-functional requirements | -Network must have sufficient bandwidth -Response time of system must be <1 second -Modified DB data must be updated within 2 seconds for all users accessing it -Downtime should be <1 hour over 3 months |
| Non-functional requirement table | SLIDE 85 IN MIDTERM REVIEW |
| Verifiable non-functional requirement | A statement using some measure that can be objectively tested |
| Guidelines for writing requirements | Avoid use of computer jargon |
| System requirements | -More detailed specifications of system functions, services, and constraints than user requirements -Intended to be basis for designing the system -May be incorporated into system contract -May be defined using UML models |
| Alternatives to NL specification | -Structured natural language -Design description languages -Graphical notations -Mathematical specifications |
| Requirements engineering process | SLIDE 103 IN MIDTERM REVIEW |
| Two types of interviewing | 1. Closed interviews where a pre-defined set of questions are answered 2. Open interviews with no pre-defined agenda and a range of issues that are explored with stakeholders |
| Interviews in practice | -Mix of closed- and open-ended interviews -Good for getting overall understanding of what stakeholders do and how they might interact with the system -Difficult to elicit domain knowledge through interviews |
| Requirements validation techniques | 1. Requirements reviews 2. Prototyping 3. Test-case generation |
| Requirements reviews | Systematic manual analysis of the requirements |
| Prototyping | Using an executable model of the system to check requirements |
| Test-case generation | Developing tests for requirements to check testability |
| Principal stages of requirements change management | 1. Problem analysis 2. Change analysis and costing 3. Change implementation |
| Problem analysis | Discuss requirements problem and propose change |
| Cost and change analysis | Assess effects of change on other requirements |
| Change implementation | Modify requirements document and other documents to reflect change |
| Change management | SLIDE 111 |
| Two major categories in UML | 1. Structure diagrams 2. Behavior diagrams |
| Use case | A particular action that a user needs to accomplish in a given system All use cases provide a complete external view of a system |
| Actor | Who or what initiates the events involved in a task User or outside system that interacts with system under design to produce intended result |
| T or F: Actors of a use case are always individuals | False |
| T or F: Every actor is a stakeholder but not every stakeholder has to be an actor | True |
| Use case include | Used to factor out steps that occur in more than one scenario Indicated by dashed line from a use case to the included steps, with an open arrow head at the included set of steps |
| System boundary | Separates the system from external actors |
| Use case generalization | Used to indicate that a given use case is a variation of, or specific version of, another use case |
| Use case extension | Indicates the extension use case will extend and augment the base use case |
| T or F: A use case may extend multiple use cases, and a use case may be extended by multiple use cases | True |
| Method call | Arrow pointing to top of activation bar in UML |
| Activation bar | Duration of the execution of message |
| Life line | Representing the time that an object exists |
| Alt | The if-else form of execution in UML |
Created by:
arctic-bird