SE MOCK PAPER QUESTIONS Flashcards
Using no more than 4 bullet points, name and describe the four fundamental
phases common to all Software Engineering projects.
- Requirements - Where you are gathering all the information you’ll need in order to implement what is asked and required for the application.
- Specification - Where you will understand what is asked to be done, is a document that will describe the software and how it’ll be expected to perform and its functionality.
- Implementation - This phase involves translating the design and the documentation into actual code, so actually implementing and writing code. for the application to be working.
- Maintenance & Testing - Tested and Deployed, and maintained where bugs can happen and all sorts of things.
Using no more than 4 bullet points, explain the difference between Requirements
and Specifications.
- Requirements represent the needs and expectations of stakeholders including users, customers and other project participant.
- Specifications on the other hand provide a detailed and precise description of how the requirements will be implemented, define the technical characteristics and constraints and functionality of the software system
- Requirements and specification are related but are still different, Requirements define the “what” of the software system and specification defines “how”.
- Requirements also tend to change a lot whereas specification is more stable and serve as a baseline for the development process, changes in requirements may lead to corresponding changes in specifications.
The same UML diagrams can be used in many different ways at different
conceptual levels. Using no more than 4 bullet points, identify one type of UML diagram
discussed in the module, and explain (optionally with an example), how it can be used
differently to convey both Requirements and Specifications.
- By using UML Use Case Diagrams it can be used to convey both requirements and specifications, this is because the requirements are expressed through each use case with actors and it really illustrates the functional requirements of the system from a user’s perspective.
- Specification can also take advantage of the UML use case diagram because it is a very good diagram to provide a detailed representation of the system’s behaviour and functionality, they can illustrate the internal interactions between various components of the system and how they collaborate to achieve specific functionalities.
- An example for the requirements phase using the use-case diagram would be an bank application, you would be able to see what the users can perform within the system so for example making a payment, receiving a payment, generating a statement, etc..
- An example for the specification phase using the use-case diagram would be a bank application where it shows the flow of activities and the systems connected to the main software so in this case would be things like, how the bank will send notifications to the phone, also how the system itself will interact with other things and how it can update information needed.
Using no more than 6 bullet points, describe each of the following Requirements
practices, and explain the difference between them: Personas, Scenarios, and User Stories.
- Personas -> Personas are used for requirements gathering, personas are used to find the stakeholders for the software, personas include a “type of people” so a fictional character where is not real, where this means the main audience, so for instance a makeup brand would target personas being women, young and old that want their skin to glow, probably with specific characteristics such as depending on the brand include things like, income, skin colour, motivations, etc..
- Scenarios are used to illustrate some interaction with a proposed system, it is also used during requirements analysis to describe the specific use of a system, it should include, statement of the purpose of the scenario, assumptions about software, the steps of the scenario.
- User Stories is an informal way of gathering requirements, is a single sentence to represent a single requirement and is used like “As a <role>, I want <goal/desire>, so that <outcome>" it's a very clear and easy way to gather requirements quickly.</outcome></role>
- All of these requirements gathering techniques differ from each other, Personas are a way of providing a view of user characteristics and motivations, scenarios represents user interactions within specific contexts, and user stories capture specific user requirements or goals in an agile development context.
Scenarios are useful for more than just the Requirements phase. Using no more
than 2 bullet points, describe how Scenarios can be used later in the testing phase, and a key
advantage of using them.
Scenarios can be used further in the testing phase to find any potential errors by creating realistic test cases that simulate user interactions and validate the system’s behaviour.
Scenarios also provide a user-centric perspective, allowing tester to understand and test the system from the end user’s point of view.
Agile Software Engineering is keen on ways of working that integrate multiple
activities. Using no more than 4 bullet points, describe four Software Engineering tasks that
are all achieved by performing Test Driven Development.
- TDD encourages developers to focus on writing testable code. This necessitates careful consideration of the software’s design and architecture to ensure that the code can be easily tested
- It means you “plan” your code so you use requirements analysis when planning so you think about the requirements and how will be implemented as a test
- When using TDD the implementation of the software code happens after tests are created meaning that developers code for the tests to pass and it creates an iterative cycle and ensuring software is reliable.
- Quality assurance and debugging, by using TDD is much easier to debug any sort of error that might have in your code as you’ll have tests for all of the code anyway, and also to ensure quality is in place as you can detect bugs early in the development process.
One benefit of Paired Programming is that one person plans the code and one
person writes the code. Using no more than 3 bullet points, describe three additional
advantages of Paired Programming.
- Increased code quality - paired programming encourages constant code review between two individuals.
- Knowledge sharing and learning - paired programming allows for the transfer of knowledge and expertise between team members.
- Improved team communication and collaboration - Paired programming promotes effective communication and collaboration within the development team
Coding conventions and code reviews also help to improve code quality, along with these practices in the questions above. Using no more than 6 bullet points, explain the 3
main roles of the Software Quality Team, and how they might manage good Software Quality
processes in a company.
- Planning for quality - Is what is expected for the team to achieve, identify standards that will be met, recommend quality-promoting processes, doing this so that everyone knows what the target quality is.
- Defining standards - Product standards, that includes documentation standards, coding conventions, class structure, etc. Where as process standards, is about reviews/testing and defined good practices at each stage of the SE process. There are also a few other standards that can be put in place such as ISO 9000 which is a standard on quality management processes
- Checking for quality - Quality reviews/inspections of the quality at each stage. So a team reviews and reports the application, focusing on finding problems and checking for completeness, missing or incorrect logical steps, etc.
The four original values of the Agile Manifesto are:
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
Using no more than 4 bullet points, explain what is meant by each these values
- Individuals and interactions over processes and tools - Prioritise collaboration and communication among team members
- Working software over comprehensive documentation: Focus on delivering functional software rather than excessive documentation.
- Customer collaboration over contract negotiation, engage with customers actively throughout the development process for better outcomes.
- Responding to change over following a plan: Embrace flexibility and adaptability to address changing requirements and deliver valuable software.
The SCRUM methodology, shown below, typically involves planning 2-4 weeks of development, involving a planning session (picking what to work on), daily stand-up meetings to discuss progress, release testing, and the delivery of an updated version of the
software. Teams typically perform a retrospective review at the end of sprint, before beginning the next. Using no more than 4 bullet points, explain how the SCRUM methodology adheres to all four of the Agile values (one bullet per agile value).
1.SCRUM emphasises the importance of meeting up as a team and getting together and having interactions, it does that by daily stand-up meetings to discuss progress, share challenges and coordinate efforts.
2. By having 2-4 weeks of development and each being a sprint it allows the team to really work and understand how the software will work instead of working on the documentation too much.
3. SCRUM is great when it comes to customer collaboration over contract negotiation, this is because SCRUM allows the customer to collaborate with the project for example in the 2-4 weeks sprint the customer gives input about certain info and certain requirements they would like and after the sprint is finished they can also review and give feedback much easier.
4. SCRUM embraces change by allowing flexibility in adjusting the product backlog and priorities during each sprint
Change management is an important part of Software Engineering. Using no more than 4 bullet points, explain the difference between managed change, and emergency
change.
1.Managed Change is planned and controller | Emergency change is unplanned and urgent
2. Managed change is scheduled and predictable | Emergency change is time sensitive and disruptive
3. Managed change has approval and evaluation | Emergency change has expedited approval from stakeholders and not much evaluation
4. Managed change has great documentation about fixes and changes | Emergency changes has limited documentation.
Using no more than 3 bullet points, explain how SCRUM enables good change
management.
- Iterative and incremental development
- Continuous feedback and adaptation
- Collaborative environment
