D284 Software Engineering

D284 Software Engineering Leave the first rating Students also studied Terms in this set (280) Save WGU - Scripting and Programming ...85 terms Pontiac1979Preview

PRE-ASSESSMENT: HEALTHCARE E...

50 terms rickss1Preview

Study.com Computer Science 307: S...

515 terms mrabrahammacias Preview FUNda Teacher Om 80/20-ruleIn the Dynamic Systems Development Method, the assumption that 80-percent of an application's features will take 20-percent of the project's total time to implement. (The 80/20-rule often applies to other situations, too. For example, 80- percent of the bugs are usually contained in 20-percent of the code.) acceptance testA test to determine whether the finished application meets the requirements.Normally, a user or other customer representative sits down the with application and runs through all the use cases you identified during the requirements gathering phase to make sure everything works as advertised.activity diagramIn UML, a diagram that represents work flows for activities. They include several kinds of symbols connected with arrows to show the direction of the work flow.adaptive development modelA development model that enables you to change the project's goals if necessary during development.administratorSomeone who manages the development team's computers, network, and other tools. Also called a system administrator.advisor userAny user who brings an important viewpoint to the project.agile developmentA development model where you initially provide the fewest possible features at the lowest fidelity to still have a useful application. Over time, you add more features and improve existing features until all features have been implemented at full fidelity.Agile ManifestoA set of four guiding principles for agile development. In brief the principles are: (1) Individuals and interactions over processes and tools, (2) Working software over comprehensive documentation, (3) Customer collaboration over contract negotiation, (4) Responding to change over following a plan

Agile Unified Process (AUP)A simplified version of Rational Unified Process that includes agile methods such as test-driven development and agile modeling. In 2012 AUP was superseded by Disciplined Agile Delivery.algorithmA software recipe that explains how to solve a particular programming problem.ambassador userSomeone who acts as a liaison between the users and the developers.anchoringA phenomenon where an early decision made by one person influences later decisions by others.anomalyIn a relational database, an error caused by a design flaw such as records holding inconsistent values or being unable to delete a piece of data because it is necessary to record some unrelated piece of information.architectSomeone who focuses on the application's overall high-level design.artifactIn a UML deployment diagram, a file, a script, an executable program or another item that is deployed. In development models, something generated by the model such as a requirements document, user story, or piece of code.assertionA statement about the program and its data that is supposed to be true. If the statement isn't true, the assertion throws an exception to tell you that something is wrong.attributeSome feature of a project that you can measure such as the number of lines of code, the number of defects, or the number of times the word "mess" appears in code comments. See also metric and indicator.audit trailA record of actions taken by an application's users for security auditing purposes.behavior diagramIn UML, a diagram that shows the behavior of some entity. There are three kinds of

behavior diagrams: activity diagrams, use case diagrams, and state machine

diagrams.Big BoardA large board used by many agile models that is posted in a visible location so that everyone can see the project's status at a glance. Also called an information radiator.big O notationA system for studying the limiting behavior of algorithms as the size of the problem grows large.black-box testA test designed by someone who doesn't know how the code works internally.brainstormingA group technique for discovering creative solutions to a problem.bugA flaw in a program that causes it to produce an incorrect result or to behave unexpectedly. Bugs are generally evil.

build engineerIn Feature-Driven Development, someone who sets up and controls the build process.burndown chartIn Scrum, a graph showing the amount of work remaining over time.business ambassadorSomeone who provides business information from the viewpoint of the users.business analystA domain expert who helps define the application's purpose and who provides feedback during development. Also called a business advisor.business requirementsThe project's high-level business goals. They explain what the customer hopes to achieve with the project.business visionarySomeone who has a clear vision of the application's business role, particularly early in the process when that role isn't clearly written down.ChangeA change to an application that is requested by customers. This may happen when customers understand the application better, when customers think of a new feature or a modification they want, or when the users' environment changes so the application needs to be changed to be useful.change control boardA group of project members, possibly including one or two customers, that reviews and approves or rejects change requests.chief architectIn Feature-driven Development, the person responsible for the project's overall programmatic design.chief programmerIn Feature-driven Development, an experienced developer who is familiar with all the functions of development (design, analysis, coding, and so on). Chief programmers lead project teams.child classA class derived from a parent class. The child class inherits properties, methods, and events from the parent class.classIn object-oriented programming, a construct that defines a type (or class) of items. For example, if you define a Customer class, you can then create many Customer objects representing different real-world customers.class diagramIn UML, a diagram that describes the classes that make up the system, their properties and methods, and their relationships.class ownerIn Feature-driven Development, the person who is responsible for a particular class's code.CleanroomA development model that emphasizes defect prevention rather than defect removal. It uses formal methods, statistical quality control, and statistical testing to prevent and detect bugs.client tierThe tier in a multitier architecture that consumes a service. This is often an application's user interface.

client-server architectureA design that separates pieces of the system that need to use a particular function (clients) from parts of the system that provide those functions (servers). That decouples the client and server pieces of the system so that developers can work on them separately.coachSomeone who helps a development team follow its chosen path (XP, Scrum, Lean, and so forth).code coverageThe lines of code that are executed during a demonstration or a suite of tests.code reviewWhen two or more programmers walk through a piece of code to look for problems. Also called a code inspection.coding standardsStandards used by a development team to ensure consistency. Standards may define conventions for variable names, comments, documentation, specific code style, and more. Coding standards make the code easier to read and debug.communication diagramIn UML, a diagram that shows communication among objects during some sort of collaboration. This is similar to a sequence diagram except a sequence diagram focuses on the sequence of messages, and a communication diagram focuses more on the objects involved in the collaboration.complexity adjustment factorsIn function point calculations, values that take into account the importance of general features of the application (such as transaction rate).complexity adjustment value (CAV)In function point calculations, the sum of the complexity adjustment factors.complexity factorIn function point calculations, you multiply each function point metric by a complexity factor to indicate how complex each activity is.component diagramIn UML, a diagram that shows how components are combined to form larger parts of the system.component interface testA test that studies the interactions between components. This is a bit like regression testing in the sense that both examine the application as a whole to look for trouble, but component interface testing focuses on component interactions.component-based software engineering (CBSE) A design that regards the system as a collection of loosely coupled components that provide services for each other.composite structure diagramIn UML, a diagram that shows a class's internal structure and the collaborations that the class allows.configuration managementManaging the items produced by the project such as requirements documents, designs, and, of course, source code. This may include controlling changes to those items so that changes don't happen willy-nil y.COTSCommercial off-the-shelf as in a COTS application.