SSE - Oral Exam Flashcards
What are some elements of a PID?
o Finding out and defining the problem to be solved
o Give the project a name
o ID the project sponsor (name, contact info)
o ID the business need – problem being solved
o ID the user roles
o ID high level user requirements
o ID the expected value (feasibility analysis)
Does the system contribute to the overall objectives of the organization?
Can the system be implemented using current technology and within given cost and schedule?
Can the system be integrated with our systems which are already in place?
Tangible and intangible values
o ID any special issues
4 ways to determine the expected value (feasibility analysis)
Does the system contribute to the overall objectives of the organization?
Can the system be implemented using current technology and within given cost and schedule?
Can the system be integrated with our systems which are already in place?
Tangible and intangible values
What are elements of software requirements?
o Finding out and defining what is required (functionality and constraints) of the software
o Analyze current situation precisely as possible
o Deliver what software client needs
o Design UI
o Create domain model (analysis model)
o Create requirements spec (SRS) – ensure correct
3 elements of an SRS - ensure correct
Legal document
Specifications must not be ambiguous, incomplete, or contradictory
Must not have phrases like “optimal” or “98% complete”
Software Engineering definition
• An application of the systematic, disciplined, and qualitative approach to the development, operation, and maintenance of software, or the study of.
o Systematic – done or acting to a fixed plan; methodical
o Disciplined – showing a controlled form of behavior or way of working
o Quantifiable – capable of being measured
Generic phases of the software lifecycle
Identification and Definition
o Define the problem, scope, needs of the customer, the risks, finding
Software requirements
o The functions required, the existing environment, any new software or application needed
Software design and implementation
o Develop and test
o Can be done in iterations
o May include regression testing after each iteration
Software validation
o Ensures the product follows the requirements and specifications outlined in the first step
o Test and regression testing
o Make sure meets the specs and the customer’s needs
Deployment and evolution
o Hand over to the customer
o Maintenance
o Training
o Updates or changes
General principles of the software engineering process (10)
- Determine the value
- KISS
- maintain a clear vision
- keep in mind that someone else will need to understand what you are doing or have done
- Plan on reuse
- think before acting
- Things change
- Design to meet those changes
- Plan ahead
Key actions of Elicitation
o Identify the product’s expected user classes and other stakeholders
o Understanding user tasks and goals and the business objective with which those tasks align
o Learning about the environment in which the new product will be used
o Working with individuals who represent each user class to understand their functionality needs and their quality expectations
What are some Elicitation methods?
Workshops / JAD - joint application design Focus groups Observations Questionnaires System interface analysis User interface analysis Document analysis Prototyping
System interface analysis
o Analysis of other connecting systems
o Identifies data exchange formats
o Identifies functional requirements
User interface analysis
o Analysis of existing UI
o Identifies user requirements
o Identifies functional requirements
o User-interface requirements
Special type of non-functional requirements, which addresses the user interface
Describes the look and feel of the product.
• “The system shall allow user interaction via a touch-screen.”
• “The system shall be judged by 75% of users to be user friendly.”
• “The system shall be ADA compliant.”
Document analysis
o Examine the documents that are currently being used – they help identify data elements and processes
o Existing documentation can help reveal how systems currently work or what they are supposed to do
o Can help identify functionality that needs to remain, or isn’t used.
o Can help identify how people do their jobs currently, what competitors offer, and what vendors say their software should do
4 steps to create use case documentation
- Identify the actors in the system
- Identify use cases
- Create use case descriptions
- Create scenarios
Business requirements
Are why the implementation is needed. The business needs the organization hopes to achieve
User requirements
The tasks and goals the user must be able to perform that will provide value to someone. They’re what the user will be able to do
Features
• These requirements consist of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements
- A feature is typically a set of requirements
- They can be represented using a feature tree
Analysis Model Elements (4)
System Model
o Represents a high-level view of the system architecture and the actors
Data Model (class diagram) o The domain objects and their relationships
Functional Model (sequence diagram) o The operations that transform data
Behavioral Model (state-machine diagram) o The behavior of the system
System modeling - use case
- Use a package to represent the system
- Show the actors and their relationships
- Show the information flow
- Use stereotypes where appropriate
6 signs that requirements are stabilizing when
- Users can’t think of new use cases
- New scenarios don’t lead to new functional requirements
- Users are repeating issues already addressed
- Suggested features, user requirements, or functional requirements are out of scope
- New requirements are all low priority
- Developers and testers raise few questions when reviewing requirements
High Level Sequence Diagram
- Can be used to analyze user interactions with the system
* Shows the time ordering of the interactions between the user and the system
Characteristics of a good requirements document (8)
- Correct – every requirement stated is one that the software shall meet
- Unambiguous – every requirement has only one interpretation
- Complete – all significant requirements; definitions of all responses to all input data; full labels and references
- Consistent – must agree with higher level documents
- Ranked for importance and/or stability – each requirement has an identifier to indicate the importance or stability of that requirement
- Verifiability – every requirement is verifiable (testable)
- Modifiable – the structure and style of the SRS can be changed easily
- Traceable – the origin of each requirement is clear and facilitates the referencing of each requirement in future documentation
Functional requirements
o Describes the computational operations of the system in terms of its inputs, outputs, and actors.
o Describes required behavior in terms of required activities, such as reactions to inputs, and the state of each entity before and after an activity occurs. – Pfleeger & Atlee
What are Non-functional requirements?
o Describes some quality characteristic that the software solution must possess. – Pfleeger & Atlee
o Define the overall qualities or attributes of the resulting system. – K & S
o Taxonomy - Sommerville
Formal methods
A particular kind of mathematically rigorous techniques for the specification, development and verification of software and hardware systems
- Involve complex math and proofs rather than ambiguous language
- A modeling language (e.g. Z) is used, which makes this an expensive and sometimes complicated process
- The testing involves proofs as part of the testing
- Best for critical projects such as safety
- Requires a developer experienced in the language
Semi-formal techniques for detailed specifications
- BNF – static description – Extended Backus-Naur form
- Class Diagrams
- Storage requirements
- Pseudocode
- Decision tables
- State machine diagrams
- Activity diagrams
- Data flow diagrams
Why is V&V important?
Requirement error costs are high.
Concerned with assuring that the specified requirements define the system that the customer really needs
Requirements validation?
People involved?
Certifies that the software requirements specification document is an acceptable description of the system to be implemented
People involved: System stakeholders, requirements engineers, and system designers
What are 5 Validation techniques?
Inspections
o Most widely used technique of requirements validation
o Involve a group of people who read and analyze the requirements, look for problems, meet and discuss the problems, and agree on actions to address these problems
Ambiguity reviews o A requirement is ambiguous if there are multiple interpretations of that requirement The missing else problem Reference ambiguity Ambiguities of omission Logical operator of ambiguity Negation ambiguity Ambiguous statements Ambiguities of built-in assumptions – don’t assume the knowledge of the reader
Conflict reviews
o Requirements conflict – the stakeholders involved must negotiate to resolve the conflict
Prototyping
o Demonstrate the requirements and help stakeholders discover problems
Test case/scenario development
o Correctness – is this what the client means? Both client and analyst should review
How to determine Quality? (5)
Reliable - consistency leads to high quality products
Robust – can accommodate unanticipated changes in tools and environment
Productive – produces results
Evolvable – can accommodate new management and organization technologies
Reusable – can be applied across projects and organizations
Verification vs Validation
Verification
Products of given phase satisfy conditions imposed at start of phase
Are we building the system right? Quality control
Validation
Ensure software meets specs, system testing, acceptance testing
Are we building the right system? Quality assurance
Build and fix model
Pros
Cons
• Basic and starts with getting the needs form the customer
• The product is then built and if it meet the needs, then gets deployed, otherwise, modifications take place and then checked again until meets the specs
• Pros
o Good for small projects
o Simple and easy to use
• Cons
o Not suitable for large projects
o Hard to manage
o Not organizedEvolutionary models?
Examples?
- Are both incremental and iterative
- The main concept is to build a functional project
- Then adding changes or functions as needed
- Iteration means small releases and if the releases are functional, are incremental
Examples
o Incremental development
o Rational unified development
o Prototyping
o Spiral method
What is CMMI?
Capability Maturity Model Integration
• Provides businesses with essential components of effective processes to improve their performance
• Identifies the business’ strengths and weaknesses and provides process changes to turn weaknesses to strengths
CMMI
Staged representation
- Provides a predefined set of process areas to define the organizations’ maturity level
- The maturity level characterizes the organizations’ capabilities and performance
CMMI
Continuous representation
- Allows organizations to select a specific process area to improve its capability level
- The capability level is the organization’s capability and performance in a specific area
CMMI
5 maturity levels – classify organizations
1 – Initial 2 – Managed 3 – Defined 4 – Quantitatively managed 5 – Optimizing
CMMI
5 capability levels – process inside of organization
0 – Incomplete – the product hasn’t started or is incomplete
1 – Performed – the product is started but does not function well. It has some benefit, but not without overspending and heroics
2 – Managed – managed processes for developing – steps are being tracked and are defined. Also includes 0 and 1 functions
3 – Defined – a better understanding of each step and its purpose. Also a better understanding of where it fits with the business needs. Also including 2, 1, & 0 functions
4 – Quantitatively managed – research help define the process and the needs. Stratistics are gathered to ensure positive product outcome. Managed steps with a clear vision for each step. Also includes function of 3, 2, 1, & 0.
• 5 – Optimizing – seeks improve – continual learning of what works and what doesn’t work. Continually searching for more efficient methods using past experience and research to make changes to the process to increase positive project outcome
Software
set of instructions that tells the computer to accomplish some task
Software Crisis
difficulty of writing useful and efficient computer programs in the required time. The crisis is due to a hardware evolving at a pace too quick to keep up
Symptoms of a software crisis
- Overbudget project
- Late projects
- Inefficient software – wasteful or slow
- Low quality software
- Software that did not meet the requirements
- Unmanageable projects
- Difficult to maintain code
- Never delivered software
Process
a series of actions or steps to build a product
Product
the actual software being created
What is the motivation for picking a process for a project
- Reducing costs while increasing quality
- The product to be correct and efficiento Correct – for each set of inputs, it results in the correct output
o Efficient – the correct output uses minimum resources where resources is speed vs memory
o Integrity
o Reusable
o Maintainable
What are 4 critical levels?
- Mission – loss of finance
- Safety – leads to loss of safety
- Production - productivity
- Life – failure leads to death
What are the 3 types of Non-Functional Requirements?
Product Requirements
• Usability, Efficiency, Dependability, Security
Organizational Requirements
• Environmental, Operational, Development
External Requirements
• Regulatory, Ethical, Legislative
