Download Software Engineering Principles and Practices and more Exams Computer Science in PDF only on Docsity!
PURDUE CS 307 FINAL EXAM
QUESTIONS AND CORRECT ANSWERS |
RATED A+
What is software? Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system Types of software Applications (video games, spreadsheets, etc.) System (OS, drivers, etc.) Embedded (firmware, microcode) Real Time (control & monitoring, often safety critical) Types of software development Custom Generic Embedded What is software engineering? IEEE: (1) the application of a systematic, disciplined, quantifiable approach to the development, operation, maintenance of software; that is, the application of engineering to software. (2) the study of approaches as in (1) Ways in which software engineering differs from other disciplines Abstract/logical vs. concrete/physical Discrete vs. continuous math Foundations in computer science not natural science No "manufacturing" phase Maintenance = evolution
Ways in which software engineering is similar to other disciplines Series of decisions Trade-off analysis conducted Work quantitatively Calibrate measurements Use approximations based on experience and empirical data Emphasize disciplined process Multiple roles for engineer Use tools Advance field through professional societies Ethical categories Public Client & Employer Product Judgement Management Profession Colleagues Self Responsibility Public ethic Software engineers shall act consistently with the public interest Client & employer ethic Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest Product ethic
Developers Managers Software quality attributes For product operation For product revision For product transition Operation attributes Correctness, Efficiency, Integrity, Reliability, Usability Correctness The degree to which a program satisfies the user's requirements Efficiency The amount of computing resources, time and space, required to perform a user-defined function or task Integrity How well is the software and data protected from security breaches and installation errors Reliability To what degree can the system be expected to perform its intended function without failure in the user's environment
Usability (Operation attributes) How much effort do the users have to spend learning to use the system efficiently Revision attributes Flexibility Maintainability Testability Flexibility (Operation attributes) How much effort will be required to enhance the system Maintainability How much effort will be required to locate and repair defects in the system Testability How much effort will be required to test the structure and functionality of the system Transition attributes Interoperability Portability Reusability
Code and fix model Code, fix, repeat until resources exhausted Waterfall model System engineering System analysis System design Implement the system Test the system Maintain the system Prototyping model Determine requirements Build a prototype Do a partial design Evaluate the system Engineer the product Evolutionary model Can become a modern version of code and fix Product evolves over time as the real requirements become known Assumes the customers will tell us what they like and dislike about each incremental release
Spiral model Determine objectives Evaluate alternatives Develop, verify next-level product Plan next phases (repeat) Scrum Roles Product owner Scrum master Development team Product owner Defines the features of the product Decides on release date and content Prioritizes features Adjusts features and priority every iteration, as needed Accepts or rejects work results Scrum master Represents management to the project Responsible for ensuring adherence to scrum practices Removes impediments Ensures that the team is fully functional Shields team from external interference
Estimate time to complete each item Assign tasks to individual members Daily scrum Fifteen minutes for team to "synchronize" and plan for the next 24 hours What has been done, what will be, roadblocks Held same time, same place Sprint review meeting Development team presents accomplishments Form of a demo of new features or progress Informal Sprint retrospective Opportunity to reflect and plan for improvements during the next sprint Sprint artifacts/documents Project charter Product backlog Sprint backlog Burn down chart Project charter Problem statement: short and succinct (one or two sentences)
Project objectives: what the project will achieve Stakeholders: persons who will be actively involved with the project Project sponsor, types of users, etc. Deliverables: major results or services that will be produced Product backlog Ordered list of everything that might be needed in the product Product owner is responsible for the backlog Never complete Lists all features, functions, requirements, enhancements, and fixes that need to be made "As a, I want, so that" Burndown chart Graphical representation of work left to do vs. time left in which to do it Domain analysis Process by which software engineer learns about the domain to better understand the problem Types of requirements Real: functional and performance Constraints: non-functional Possible: non-measurable, subjective, political Probably not: expectations, wishes, desires
Think "hardware interrupt" Use Case Diagrams Generalizations Represents several similar use cases Similar to superclasses in a class diagram Use Case Diagrams Inclusions Allow one to express commonality between several use cases Included in other use cases Represent the performing of a lower-level task with a lower-level goal Steps to managing requirements Review them Track them Verify them Control the changes to them Requirement review considerations Benefits Important Unambiguous Consistent Quality Realistic Verifiable
Identifiable Cons to reusability Takes extra time Sometimes only reward visibility Costs money Pros to reusability Prevents taking shortcuts Should be part of the culture Framework Reusable software that implements a generic solution to a generalized problem Framework slots Certain classes or methods are missing Framework hooks Optional functionality, allowance made for developer to provide it Product line Set of products built on a common technology base
Advantages of client-server Work is distributed Client can access server from distance Client and server can be designed separately Data stored centrally at server Thin-client Client is as small as possible Most work done on server Fat-client As much work as possible delegated to clients Server handles more clients UML A "general purpose" modeling language Provides a standardized method for designing a system Types of UML diagrams (and static/dynamic) Class diagrams (static) Composite structure diagrams (static) Sequence diagrams (dynamic) Activity diagrams (dynamic)
State machine diagrams (dynamic) Class diagram Describes system attributes, operations, relationships among objects Composite structure diagram Shows internal structure of a class Parts: runtime role of a classifier (e.g., class) or a collection of instances Port: connects classifiers with their parts and environment Connector: binds two or more entities together Activity diagrams Graphical workflow showing stepwise activity and actions Similar to a state diagram except most transitions caused by internal events Can represent concurrency Visualize interrelation and interaction between different use cases Association Shows how two classes relate to each other Multiplicity (*, #, ..) Many, Number, Or
Shows the sequence of messages exchanged by a set of objects performing a specific task Actor on left Messages are arrows between sender and receiver Lifeline attached to each object/actor State diagram Describe the behavior of a system, part of a system, or an individual object Fork One incoming transition, multiple outgoing transitions Join Multiple incoming transitions, one outgoing transition Rendezvous Multiple incoming and multiple outgoing transitions Swimlanes Partition activities among classes Developer quality issues Testable Maintainable
Enhanceable Correct Robust Reliable Installable Liability Manufacturable Marketable User quality issues Affordable Valuable Correct Usable Learnable Robust Safety Security Serviceable Tailorable
