Questions 100% on Flashcards
Fundamental activities that are common to all software processes includes: Specification,design and implementation, validation, and evaluation.What does a software engineer do during the validation process?
-defining the organization of the system and implementing the system
-checking that it does what the customer wants
-defining what the system should do
-changing the system in response to changing customer needs
-Checking that it does what the customer wants
What would be a direct benefit of requirement validation?
-Put documents in nice format
-Help agile development
-Reduce the cost of having to fix issues after delivery
-Get more requirements from stakeholders
-Reduce the cost of having to fix issues after delivery
What are some of the requirements elicitation techniques?
-Interview uses of the system
-Develop the system
-Refactoring
-Observe the existing system
-Improve reliability of the system
-Interview uses of the system
-Observe the existing system
Why agile development is not a good choice for long-lifetime systems?
-Because they can’t deliver software fast enough
-Having the development team in the same location
-The whole team attends daily short meetings
-Hard to track the backlog to find work that needs to be done
-Original developers will not always stay at the same job
-Original developers will not always stay at the same job
Which of the following is a true statement about generic product?
-Software that is commissioned for specific customer need
-Software that is developed to maintain the hardware in a specific factory
-Software made for any customer who wants to buy it back
-Banking app made for specific bank to manage its internal activities
-Software made for any customer who wants to buy it back
What are the characteristics of agile development?
-Detailed documentation
-Mostly focused on coding
-Frequent delivery of new versions
-Implementation starts after the system design has been fully completed
-Minimal documentation
-None of the above
-Mostly focused on coding
-Frequent delivery of new versions
-Minimal documentation
Despite the many advantages the “integration and configuration” model brings to the table, there are several disadvantages to using such a model.(select all that apply)
-Requirements may be compromised due to reusable components not having everything the user needs
-Being able to deliver the software faster
-Loss of control over evaluation due to reused elements belonging to another company
-The programmers having to start writing new codes from scratch
-None of the above
-Requirements may be compromised due to reusable components not having everything the user needs
-Loss of control over evaluation due to reused elements belonging to another company
What are the essential attributes of good software?
-Maintainability
-Dependability and security
-Efficiency
-Acceptability
Application Types
-Stand-alone applications
-Interactive transaction-based applications
-Embedded control systems
-Batch processing systems
-Entertainment systems
-Systems for modeling and simulation
-Data collection systems
-Systems of systems
Software Engineering Ethics
-Confidentiality
-Competence
-Intellectual Property Rights
-Computer Misuse
Four common activities in software process
-Specification
-Design and implementation
-Validation
-Evolution
The Waterfall Model Phases
-Requirements analysis and definition
-System and software design
-Implementation and unit testing
-Integration and system testing
-Operation and maintenance
Waterfall Model Problems
-Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.
-The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.
Incremental Development
-This is based on the idea of developing an initial implementation, getting feedback from users & others, and evolving the software through several versions until the required system has been developed
-Specification, development, and validation activities are interleaved rather than separate, with rapid feedback across activities.
Integration and configuation model
-In the majority of software projects, there is some software reuse. This often happens informally when people working on the project know of or search for code that is similar to what is required.
-Based on software reuse where systems are integrated from existing components or application systems (sometimes called COTS -Commercial-off-the-shelf) systems).
-Reused elements may be configured to adapt their behavior and functionality to a user’s requirements
-Reuse is now the standard approach for building many types of business systems.
Component Testing
-Individual components are tested independently, without other system components.
-Components may be functions or objects or coherent groupings of these entities.
System Testing
-Testing of the system as a whole. This process is concerned with finding errors that result from unanticipated interactions between components and component interface problems. It is also concerned with showing that the system meets its functional and non-functional requirements.
Customer Testing
-This is the final stage in the testing process before the system is accepted for operational use. Testing with customer data to check that the system meets the customer’s needs.
System Prototyping
-where a version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of design decisions. This approach supports change anticipation. Changes required after delivery will be reduced.
-A prototype is an initial version of a system used to demonstrate concepts and try out design options.
Agile Development
-Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process.
Extreme Programming
Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.
-New versions may be built several times per day
-Increments are delivered to customers every 2 weeks
-All tests must be run for every build and the build is only accepted if tests run successfully.
Refactoring
-Refactoring is the process of restructuring existing code without changing any of its functionality
-Conventional wisdom in software engineering is to design for change. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle.
-XP, however, maintains that this is not worthwhile as changes cannot be reliably anticipated.
-Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.
Test-first development
-Testing is central to XP and XP has developed an approach where the program is tested after every change has been made. Development cannot proceed until test cases have been developed.
-XP testing features:
–Test-first development.
–Incremental test development from scenarios.
–User involvement in test development and validation.
–Use of automated testing frameworks. Automated test harnesses are used to run all component tests each time a new release is built.
Scrum
-an agile method that focuses on managing iterative development rather than specific agile practices.
Phases of Scrum
-The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture.
-This is followed by a series of sprint cycles, where each cycle develops an increment of the system.
-The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project.
Scrum Roles
-First the product owner. Key stakeholder with a vision who provides direction to the team for each sprint.
-Team members(5-9 professionals) in various disciplines who are jointly responsible for the result.
-The scrum master, the facilitator who focuses completely on the process.
Scrum “velocity”
-An estimate of how much product backlog effort that a team can cover in a single sprint. Understanding a team’s velocity helps them estimate what can be covered in a sprint and provides a basis for measuring improving performance.
Product Backlog
This is a list of ‘to do’ items which the Scrum team must tackle. They may be feature definitions for the software, software requirements, user stories or descriptions of supplementary tasks that are needed, such as architecture definition or user documentation.
Multi-team Scrum
-Scrum has been adapted for large-scale development. Multiple Scrum teams are set up. The key characteristics of multi-team Scrum are:
-Role replication
–Each team has a Product Owner for their work component and ScrumMaster.
-Product architects
–Each team chooses a product architect and these architects collaborate to design and evolve the overall system architecture.
-Release alignment
–The dates of product releases from each team are aligned so that a demonstrable and complete system is produced.
-Scrum of Scrums
–There is a daily Scrum of Scrums where representatives from each team meet to discuss progress and plan work to be done that day.
User Requirements
-Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
System Requirements
-A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.
Stakeholder
-Any person or organization who is affected by the system in some way and so who has a legitimate interest
Stakeholder Types
-End users
-System managers
-System owners
-External stakeholders
Functional Requirements
-Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
-May state what the system should not do.
-Describe functionality. What the system should do.
-A function of a system or component.
-What should be the inputs, behaviors, and outputs.
-Functional user requirements may be high-level statements of what the system should do.
-Functional system requirements should describe the system services in detail.
Non-functional requirements
-Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
-Often apply to the system as a whole rather than individual features or services.
requirements elicitation
-Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.
-May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.
requirements elicitation stages
-Requirements discovery: Interact with stakeholders to discover their requirements.
-Requirements classification and organization: take the unstructured collection of requirements, group related requirements, and organizes them into clusters.
-Requirements prioritization and negotiation: when multiple stakeholders are involved, requirements will conflict. Agree on compromise requirements and prioritize them.
-Requirements specification(documentation): an early draft of the software requirements documents may be produced at this stage.
Requirements elicitation techniques
-Interviewing, where you talk to people about what they do.
-Observation or ethnography, where you watch people doing their job to see what artifacts they use, how they use them, and so on.
Requirements Specification
-Requirements specification is the process of writing down the user and system requirements in a requirements document.
-User requirements have to be understandable by end-users and customers who do not have a technical background.
–Ideally, they should specify only the external behavior of the system.
–Should not include details of the system architecture or design.
-System requirements are more detailed requirements and may include more technical information.
–May be used as a part of a contract for the system development.
–It is therefore important that these are as complete as possible.
Requirements Validation
-Concerned with demonstrating that the requirements define the system that the customer really wants.
-Requirements error costs are high so validation is very important
–Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
