Download Software Engineering Methodologies & Testing Q&A 2026–2027 and more Exams Computer Science in PDF only on Docsity!
11: software engineering, methodologies,
testing questions and 100% verified answers
2025/2026 latest update 1.Computer science - answerfocuses on theory and fundamentals
2.Software engineering -developing and delivering software answeran engineering discipline that is concerned with the practical aspects of
3.What percentage of software costs are for development compared to testing in 2015? -35%, Development 65% answerTesting
4.What would make a manager say that a software project has failed? (4) -buggy answer- not functional or
- missing critical features
- over schedule- over budget
5.What percentage of projects are either over schedule or over budget? -IT projects were over budget, and 2016 55% of all ITP projects had failed answer2004 nearly 75% of all
6.Why does software engineering fail? (6) - answer- bad estimate
- each project is different in some way- larger systems are being created
- technology changes rapidly- more complex systems that may need capabilities that are not handled by existing software engineering techniques- don't use formal software engineering which leads to communication issues in team
7.Software Engineering Intent -programming answersupport professional software development, not individual
8.Four Fundamental activities common to all software -- Development: program what is needed answer- Specification: define what is needed
- Validation: ensure the program is what is needed- Evolution: modify the program based on new requirements
9.Plan-based software engineering -projects (ie. waterfall, incremental, reuse-oriented, spiral) answerproduces a large amount of documentation for sustainable
10.Agile-based software engineering -more adaptability to changing requirements (ie. eXtreme Programing (XP), Scrum, Scrum-but) answersacrifices documentation for earlier release dates and
11.Waterfall model (Royce's) (Plan-based) -off before moving to the next answerFollows a strict lifecycle where each phase is signed
12.Waterfall model phases -2. Design answer1. Requirements
- Implementation4. Verification
- Maintenance 13.Incremental development (agile) -comment, and evolves through several versions answerdevelops an initial implementation, exposes this to user
14.Incremental development pros (3) -requirements is reduced answer- cost of accommodating changing customer
- easier to get customer feedback on development
- more rapid delivery and deployment of useful software to the customer 15.Incremental development cons (2) -measuring progress answer- process is not visible so management has a hard time
Individuals and interactions over processes and tools Working software over comprehensive documentationCustomer collaboration over contract negotiation Responding to change over following a plan Pair programming in eXtreme Programming (XP) -software answerprogrammers work in pairs to develop
Pros of pair programming in eXtreme Programming (5) -ownership answer- supports the idea of collective
- acts as an informal review process
- helps support refactoring- productivity of most pair programming rivals that of two programmers working independently
- less rework, fewer errors Scrum -agile software engineering answerfocuses on managing iterative development rather than specific technical approaches to
Scrum length of sprints - answerFixed length, normally 2-4 weeks Scrum starting point for planning - answerProduct backlog (the list of work to be done on the project) Scrum selection phase -functionality to be developed in the sprint answerInvolves all of the project team who work with the customer to select
Scrum team organization -meetings to review progress and reprioritize work answerorganizes themselves to develop the software through short daily
Scrum end of sprint -sprint cycle answerwork is reviewed and presented to stakeholders before beginning the next
Scrum master -measures progress, and communicates with customers answera facilitator who arranges daily meetings, tracks the backlog, records decisions,
T/F The scrum master can change for each sprint - answerTrue T/F There is a top down direction from the scrum master - answerFalse: everyone participates in scrum Documentation in waterfall (7) -2. High level requirements answer1. Concept
- Technical specification4. Detailed design
- Testing6. Implementation
- Deployment Black box testing -of a system to identify the test cases answertest the entire application without looking at the code, uses the specifications
White box testing - answertest the entire application while looking at the code Unit testing - answertest individual functionality of the code by writing customized programming Stress testing - answertest the extensibility of the program by trying to find the limits Regression testing -the program answerwhen changes are made make sure the changes don't affect other parts of
Testing process goals (2) -software meets its requirements answer1. to demonstrate to the developer and the customer that the
Component testing System testing Unit testing (development) - answerwhere individual program units or object classes are tested Component testing (development) -composite components answerwhere several individual units are integrated to create
System testing (development) -and the system is testing as a whole answerwhere some or all of the components in a system are integrated
T/F With all types of testing there are black box and white box testing - answerTrue Component testing interfaces (4) -Shared memory interfaces answerParameter interfaces Procedural interfacesMessage passing interfaces
Parameter interfaces (component testing) -passed from one component to another answerinterfaces in which data or function references are
Shared memory interfaces (component testing) -between components answerinterfaces in which a block of memory is shared
procedural interfaces (component testing) -set of procedures that can be called by other components answerinterfaces in which one component encapsulates a
Message passing interfaces (component testing) -service from another component by passing a message to it answerinterfaces in which one component requests a
Differences between system testing and component testing (2) -components that may have been separately developed or COTS products may be integrated with other answer- during system testing, reusable components
- components developed by different team members or groups will be integrated at this stage Test Driven Development (TDD) -testing and code development answeran approach to program development in which you interleave
T/F Test Driven Development (TDD) was introduced as part of plan-based methodologies -introduced as part of agile methodologies (scrum, XP) answerFalse:
T/F Test Driven Development (TDD) greatly reduces the cost of regression testing - answerTrue Release testing -outside the development team answerthe process of testing a particular release of a system that is intended for use
Differences between release testing and system testing (2) -involved in the system development should be responsible for release testing answer- a separate team that has not been
- release testing checks that the system meets its requirements and is good enough for external use Release testing types (3) - answerRequirements-based testing Scenario testingperformance testing
Requirements based testing (release) - answerprovides one or more test cases for each requirement Scenario based testing (release) -test cases based on them answerdevises typical scenarios of use of the system, then develops
Performance testing (release) -load tests or stress tests) answerensures that the system can process its intended load (also called
fault repairs (software maintenance types) -errors are more expensive, and requirements errors are the most expensive answercoding errors are relatively cheap to repair, design
environmental adaptation (software maintenance types) -software changes causing the system to be modified to adapt answerhardware, OS, or other support
functionality addition (software maintenance types) -response to organizational or business change answerwhen the system requirements change in
Why is adding functionality after a system is in operation more expensive than implementing the samefunctionality during development? - answerTeam stability: the development team may be broken up and reassigned after a system has been deliveredPoor development practice: a maintenance contract may be given to a different company than the original development companyStaff skills: maintenance staff are often inexperienced and unfamiliar with the application domain Program age and structure: as the program ages, it becomes harder to understand and change sincechanges to programs tend to degrade the program structure
