Studied by 142 peopleTags & Description
Software Engineering
Engineering discipline that is concerned with all aspects of software production from conception to operation and maintenance
Differences between CS and SE
CS: Theories and methods/fundamentals of software systems
SE: Practicalities of developing software
Confidentiality
Engineers should respect confidentiality irrespective of whether or not an agreement was signed
Competence
Not knowingly accept work that is outside their skill level
4 fundamental activities of SE
Requirements/specifications
Dev/Design and Implementation
Verification/Validation
Maintenance/Evolution
Requirements/specification
Where customers and engineers define software to be produced and constraints
Development/Design and Implementation
where software is designed and programmed
Verification/Validation
Where software is checked to ensure that it’s what’s required
Maintenance/Evolution
where software is modified to reflect changing customer and market requirements
Why not base project on prototype?
Prototype is to simply answer a question, not part of whole project since it’s build quickly w/ little care
Work products used for/created from REQUIREMENTS
artifacts, specifications
Work products used for/created from IMPLEMENTATION
source code
Work products used for/created from VALIDATION
Test cases, software w/ defects removed
Work products used for/created from EVOLUTION
artifacts, specifications, source code, test cases, software w/ defects removed
Steps of waterfall diagram
Requirements definition
System & software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
Waterfall
plan driven process that requires the previous step to finish b4 starting next one
incremental
based on idea of developing initial implementation, getting feedback, and evolving versions until required system has been developed
integration and config
Dev process focuses on configuring components for use in new setting and integrating them to the system.
Waterfall Pros
Good for hardware development/high manufacturing costs.
Predictable
Good for stuff that requires planning
Good for minimal change
Waterfall Cons
Does not adapt to change well
Lots of documentation
If a step is incorrect, redo from said step
No visibility
Product isn’t ready until after completion
Incremental Pros
Parts are working earlier
Deliver to customer earlier
Get feedback during the design
Not as document heavy
Better than a waterfall approach for systems whose requirements are likely to change during the development process
Incremental Cons
Refactoring problems: Redo structure of the code
Lots of rework
Erosion in clarity and quality
More requirements
System structure tends to degrade as new increments are added
Given these: which SDLC best describes this?
Requirements known
Requirements unchanged
Customer desire
No visibility
Waterfall method
Given these: which SDLC best describes this?
Most functionality
Short budget
Short schedule
Integration and Configuration
Prototype
An early version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions.
V-Model (photo)
V-Model
shows the software validation activities that correspond to each stage of the waterfall process model.
Requirement
Fundamental to software engineering endeavors. Determine what the customer needs/wants and a basis of your product. Are what the functionality a program needs to have.
Functional Requirement
Something that the system will be able to do. Can you test it?
Nonfunctional Requirement
How the system will do something, and how well it does it.
applies to entire system
not in place
ility: readability, availability, security, efficiency
Elicitation and analysis
Range of system stakeholders to find out about the application domain, services that the system should provide, required system performance, hardware constraints, other systems, etc.
Stages of elicitation and analysis
Requirements Discovery
Requirements classification and organization
Requirements prioritization and negotiation
Requirements specification
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.
Prototyping is an example of this
Management
Process of managing changing requirements during the requirements engineering process and system development.
New requirements emerge as a system is being developed and after it has gone into use.
Critiques for requirements
a. Vague
b. Conflicting
c. Not written as a requirement
d. Not testable
e. Non precise
f. More than one requirement in one sentence
Purpose of software process
The activities and processes that are involved in developing and evolving a software system.
Steps of SEI Capability Maturity Model (SEICMM)
Initial
Managed
Defined
Quantitatively managed
Optimizing
Single arrow from each step pointing to the next one
SEICMM Initial
no process at all, free
SEICMM Managed
Basic schedule and planning, free
SEICMM Defined
Software process is defined, training of individuals
SEICMM Quantitatively managed
Measuring thing and use results to make things better, expensive
SEICMM Optimizing
Able to handle large changes with minimal hiccups, expensive
Stakeholder
Include anyone who is affected by the system in some way and so anyone who has a legitimate interest in it.
user requirements
Client managers
system end users
client engineers
contractor managers
system architects
System requirements
System end users
client engineers
system architects
software developers
stakeholders
problems with natural language specification
Lack of clarity
Precision is hard w/o making doc hard to read
Requirements confusion
Functional and Non-functional requirements tend to be mixed-up.
Requirements amalgamation
Several different requirements may be expressed together.
advantages of natural language specification
Expressive, intuitive, universal
Understandable by users and customers easily
4+1 Model (image)
Way of writing system requirement specs: Natural language
The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.
Way of writing system requirement specs: Structured Natural Language
The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.
Way of writing system requirement specs: Graphical Notation
Graphical models, supplemented by text annotations, are used to define the functional requirements for the system. UML (unified modeling language) use case and sequence diagrams are commonly used.
Way of writing system requirement specs: Mathematical Notation
These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want, and they are reluctant to accept it as a system contract.
Requirements Validation checks
Validity, Consistency, Completeness, Realism, Verifiability
Requirements Validation checks (in depth)
Requirements reviews
Systematic manual analysis of the requirements
Verifiability, Traceability, Comprehensibility
Prototyping
Test-case generation
Requirements spreadsheet
never reuse requirements ID, each one has a unique ID (UID)
How to determine if requirement ID is active
active flag will be on, or off (strikethrough), test cases for each of the requirements at the bottom
Sequences diagram
Shows interactions between actors and the system and between system components.
Class diagram
Shows the object classes in the system and the associations between these classes
Static type of diagram
Use case diagram
Show interactions between system and it’s environment.
Be familiar with the following diagrams.
Use Case, Sequence, Class, Generalization, Aggregation, State, Process, Data Flow
context diagram
Illustrates the separational context of a system
Shows what lies outside of system boundaries
based on perspective of center system
Generalization diagram
Rather than learn the detailed characteristics of every entity that we experience, we place these entities in more general classes (animals, cars, etc) and learn the characteristics of these classes. (OOP)
Aggregation diagram
shows how classes that are collections are composed of other classes
similar to part-of relationship in semantic data models
State diagram
shows how system reacts to internal and external events
Process diagram
reveal how system is used in broader business processes
Dataflow diagram
Tracking and documenting how data associated with a particular process moves through the system help analysts and designers understand what is going on in the process
When to use: context diagram
Simple, shows dependencies and connections to others systems. Are good to show to managers and clients who don't know about the inner workings of the system.
When to use: use case diagram
Demonstrate the different ways that a user might interact with a system.
When to use: sequence diagrams
where it is important to understand how different objects or components interact with each other over time
When to use: class diagrams
When developing an object oriented system model. Objects are to be used to represent something in the real world
When to use: generalization diagrams
Specifically represent the inheritance hierarchy of classes in a system
When to use: aggregation diagrams
A big object that uses smaller objects but the smaller objects are independent of that big object and can be amongst different big objects.
When to use: state diagrams
Used to show system states and events that cause transitions from one state to another.
When to use: process diagrams
Whenever there is a need to understand, analyze, design, document, or communicate a process. Visualize the steps involved when designing a new process and the relationships between the steps.
When to use: data flow diagrams
Used to show how data flows within the system between processing steps. Simple and intuitive and so are more accessible to stakeholders.
Software Architecture
Concerned with understanding how a software system should be organized and designing the overall structure of the system.
Affects the performance, robustness, distributability, and maintainability of a system
Architectural Quote
"architecture is where non functional requirements are realized"
Why is architecture important?
Architecture is where non-functional requirements are realized.
The critical link between design and requirements engineering.
Identifies main components in a system and relationships between them.
Output is an architectural model that describes how a system is organized.
Example of non functional requirements being met by architecture
If system has to be fast, the architecture has to have low overhead.
Layered Architecture
Each layer only talks to the layer directly above and directly below it.
Easy to switch layers out, only affects adjacent layers.
Able to change one layer without touching other layers.
Model View Controller
Breaks software into 3 pieces (Model, View, and Controller)
View is highly changeable. Can easily swap the interface without touching anything else.
Repository Architecture
Generally used for databases.
Everything (data/info) goes into a center project repository.
Minimizes coupling, components are independent of each other.
Single point of failure.
May be inefficient.
Client Architecture
Client connects to many servers (many to one).
Each service is a single point of failure, but multiple servers allows it to be robust.
Modularity benefits and fault tolerant.
Pipe and Filter Architecture
Output of 1 stage goes in as the input of another stage.
Batch processing.
Really easy to add another stage of processing, you only need to know what goes in and what is going out.
Not good for things that demand responsiveness.
Compilers are an example.
types of client architecture
Thin: Client doesn’t have a lot of code/functionality
Thick/Fat: More functionality (more JavaScript in a webpage), more responsive
4+1 Diagram: Logical View
Concerned with the functionality that the system provides to end-users.
Class and state diagrams
End user functionality: connects to scenarios and development and process view
4+1 Diagram: Development view
Illustrates a system from a programmer's perspective and is concerned with software management.
Package and component diagram
Programmers, software development: connects to scenarios and physical view
4+1 Diagram: process view
Deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the run time behavior of the system.
Addresses concurrency, distribution, integrator, performance, and scalability, etc.
Sequence/communication/activity diagram
Integrators, performance scalability: connects to scenarios and physical view
4+1 Diagram: Physical view
PoV of a system’s engineer. Concerned with the topology of software components on the physical layer as well as the physical connections between these components.
Deployment diagram
System engineers, topology, communications: connects to scenarios
3 tiered layered web app architecture
In descending order: Display, business logic, database
Display usually at top and database at bottom, rest are interchangeable
Starting point
Base initial design on a generic application architecture. Specialize later for the system being developed.
Design checklist
compare design to generic app architecture, check for consistency
Organizing work
Assign work to people to implement different components within the architecture.
Accessing components for reuse
If there are components that may be reused, compare with generic structures to see whether there are comparable components in the application architecture.
Vocab for discussion
Use the concepts identified in the generic architecture to discuss and compare applications.
4+1 Diagram: Scenarios
Serve as a starting point for tests of an architecture prototype.
Use case diagram
Every other part connects to this, the “+1” part of the 4+1 diagram
Integration & Config Pros
Cheaper
Available right away (faster)
Reliable
Integration & Config Cons
Does not do exactly what you want it to do.
Evolution of the system is harder to do, some components are not controlled by you, so newer versions may not be in sync with what you want to accomplish.
Step 1 of 4 Fundamental Activities of SE
Requirements/Specifications
Step 2 of 4 Fundamental Activities of SE
Development/Design and Implementation
Note
Flashcard