Please enable JavaScript.
Coggle requires JavaScript to display documents.
CSCI 467 Software engineering map - Coggle Diagram
CSCI 467 Software engineering map
Introduction
:star:
Professional software dev
Generic products VS Customized Products
Software engineering is a engineering discipline concerned with all aspects of software production
Software Process Activites
Specification
Development
Validation
Evolution
Link :red_flag:
Application Types
Stand-alone: runs on local computer, no networking
Interactive transaction app: remote comp, accesses web app, e commerce
Embedded control systems: Control and manage hardware, lots of these
Batch process: business systems process data in large batches
Entertainment systems: personal use, for entertainment
Modeling and simulation : for scientists to model things
Data collection: systems collect data from environment for processing
Systems of Systems: nested systems
Software Fundamentals/ Web dev
Managed
Dependable
Software specifications
Reuse software
Internet software engineering
:warning:
Software Reuse: commonly used from existing components
Incremental and agile dev
Link to this section from section 1 :red_flag:
Service oriented
Rich interfaces
Software engineering ethics
Ethical behavior following a set of principles
Confidentiality
Competence
Property rights
Computer misuse
ACM/IEEE code of ethics
Rules
1: Public interest 2: Best interest of client and employer 3: Product is professional 4: Judgment is professional 5: Managment is ethical 6: Profession is always considered 7: Colleagues are supportive 8: Self care and lifelong learning and professionalism
Dilemmas
Case Studies
Personal pump
Health case patient managment system
wilderness weather station
iLearn
Sections: 2,3,4,5
:star:
2:SW Processes
The software process
Process Descriptions: Products, Roles, Pre-Post conditions
Plan - Driven VS Agile Processes
Plan Driven: Planned process activities , progress is mesured
Agile processes: planning is
incremental
and easy to change
Process Activities
:star:
The four basic activities of specification, development, validation, and evolution are organized differently. For example, waterfall model -> sequence. Incremental -> interleaved
THE REQUIREMENTS ENGINEERING PROCESS
REP is the process of developing a software specification
:check:
Generic model of design process
Design activities: architectural design, database, interface, component
Software VALIDATION: Verification and Validation(V&V) is mostly TESTING to show that a system conforms to specifications made by the REP model
:check:
Testing stages: Component, system, acceptance
EVOLUTION: Software must be flexible while requirements change, and the difference between development and evolution is
INCREASINGLY IRRELEVANT
:check:
Coping with change: Change happens in all software and leads to REWORK
To REDUCE THE COST of REWORK: use
CHANGE ANTICIPATION
to guess changes ahead of time and
CHANGE TOLERANCE
to be accommodated at low cost :check:
This includes prototyping and incremental delivery
:check:
1 more item...
Software Process Models
:star:
WATERFALL MODEL
Phases: - Req analysis , -System and soft design, -Implementation, -Integration and system testing, -Operation and maintenance
:check:
Incremental Dev
Re-use oriented
Process Improvement :star:
Used to enhance quality , reduce costs, and speed up dev
Approaches: Process maturity -> improved project management and practices. Agile -> iterative development
Process improvement activities
: Measurement -> measure the attributes of the software process. Analysis -> Current process is assessed. Change -> Changes are proposed to address process weakness
Capability maturity levels
SEI capability maturity model: Initial, managed, defined, quantitatively managed, optimizing :check:
3:Agile SW Processes
Development types :star:
Rapid Software Development: Most important requirement for software systems
Agile development: Program specification and design/implementation is INTERLEAVED.
Practical dev methods include both
AGILE METHODS :star:
I
ncremental development methods that focus on rapid software development. It reduces overhead and minimized documentation while producing high quality code
AGILE MANIFESTO
Applicability: small- medium sized product. Custom system development
Principles: Customer involvement, incremental delivery, people not processes, embrace change, maintain simplicity
AGILE Development Techniques :star:
EXTREME PROGRAMMING: extreme iterative dev
EXP practices: incremental planning, small releases, simple design, test-first development, refactoring
EXP practices 2: pair programming, collective ownership, continuous integration, sustainable pace, on site customer
USER STORIES : requirements are expressed as user stories or scenarios
REFACTORING: constant code improvement where changes are easier to make. Looking for all possible improvements even if not needed.
TEST FIRST DEVELOPMENT: writing tests beforehand. All previous and new tests are run when functionality is added
Test automation: quick easy auto tests
PAIR PROGRAMMING: work in pairs to dev code
AGILE PROJECT MANAGEMENT :star:
Manage project so software is delivered on time
SCRUM: is an agile method that provides a project management framework
Phases: initial, sprint cycles, project closure
TERMS: Dev team, Potentially shippable product increment, product backlog, product owner
TERMS 2: Scrum, ScrumMaster( ew) , Sprint, Velocity
Sprint cycle is 2-4 weeks. Starts with product backlog
SCALING AGILE METHODS :star:
Scaling up agile methods involves changing to cope with larger longer projects
Scale up and out . Up -> can not be done by small team. Out-> introduced across a large company
Agile maintenance: lack of documentation, keeping customers involved, and continuity of the dev team
Factors in large systems
This is difficult and large systems need up front design and doc
4:Req Engineering
RE is the process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed.
Whats a requirement? High-level statement - or math function specification
Requirements abstraction: solution is not per-defined and so multiple contractors can bid
TYPES:
USER requirements: statements in natural language
SYSTEM requirements: structured document setting out detailed descriptions of system functions
SYSTEM STAKEHOLDERS: any person or organization who is affected by the system or has an interest
Functional and nonfunctional requirements
:star:
TYPES:
FUNCTIONAL: statements of services the system should provide. How should the system react, and what NOT to do
NON-FUNCTIONAL: Constraints on the services, apply to system as a whole
More critical than functional RQ. System could be USELESS if not met
Could also affect overall architecture and something such as security could generate more functional RQ
NON FUNCTIONAL CLASSIFICATIONS
Product requirements
Organizational requirements
External requirements
Very difficult to state must have a
GOAL->
a general intention to user . and
VERIFIABLE ->
a statement using some measure that can be tested
Domain requirements? Constraints on the system from the domain of operation
Imprecision
Problems with functional requirements are not precisely stated, they are interpreted differently by devs
Completeness and Consistency: Requirements need to be COMPLETE and CONSISTENT ,
CANNOT PRODUCE A C&C REQUIREMENTS DOC
Usability RQ
Should be easy to use!
Speed
Size
Ease of use
reliability
robustness
Portability
REQUIREMENTS ENGINEERING PROCESS :star:
The processes used for RE vary but here are the generic RQ
Elicitation
Sometimes called discovery
Software engineers work with a range of stakeholders to find services needed.
Stages:
Discovery
Classification and organization
Prioritization and negotiation
Specification
Problems: Stakeholders suck and don't know about code, politics, or new stakeholders
Analysis
Validation
Management
RE is iterative and interleaved
Spiral of the RE process
Interviewing :star:
TYPES:
CLOSED: based on list of questions
OPEN: explore with stakeholders
Problems: Engineers dont know what the company does. Oversight of easy stuff
ETHNOGRAPHY :star:
A social scientist basically observes the process to make it more efficient
REQUIREMENTS SPECIFICATION & VALIDATION :star:
Process of writing down the user and system RQ in a REQUIREMENTS DOCUMENT
System RQ specification should include
Natural language
Stuctured language
Graphical notation
design and description languages
mathematical specifications
USE CASES: a kind of SCENARIO that are included in UML
Should describe all possible interactions within the system
HIGH LEVEL model , UML sequence diagrams are used to show more detail
SOFTWARE RQ DOCUMENT: is the official statement of what is required of the system devs. NOT A DESIGN DOC :check:
Validation: RQ define the system that the customer really wants
This involves
REQUIREMENTS CHECKING
: Validity, consistency , completeness, realism, venerability
How its done:
RQ reviews
Prototyping
Test-case generation
If requirements change , we choose if they should be accepted
5:System Modeling
System modeling is the process of developing abstract models of a system, with each model presenting a different view or perceptive of the system
UML Diagram Types :star:
Activity
Use case
Repressnets a discrete task that involves external interaction with a system
Actors are people or other systems
Sequence
Sequence diagrams are UML used to model interactions between actors and objects
Objects and actors are listed at the top, interactions are drawn with arrows
Class
Class diagrams are used to show the classes in a system
An object can be a definition, an association is a link between the classes
Object Class Aggregation : an aggregation model shows how classes that are collections are made of other classes. Are similar to data models
State
Behavior of system in response to events
State machines modeled as nodes. Changes states
State charts to represent state machine models
Meant to be used to
FACILITATE DISCUSSION
about a system , document it , and give a detailed system description that can be used to implement
CONTEXT MODELS :star:
Used to show the operational context of a system
System boundaries define what is inside and outside the system
Show how the other systems in the environment, NOT HOW IT IS USED
INTERACTION MODELS :star:
Model user interaction, system to system, and component interactions
Can be USE CASE or SEQUENCE
STRUCTURAL MODELS :star:
Display the organization of a system in terms of components that make up a system
This can be a class diagram
BEHAVIORAL MODELS :star:
Models dynamic behavior of a system as it executes. Shows what happens or suppose to happen
TYPES:
DATA: some data arrives and has to be processed
EVENTS: some event that happens triggers the system.
Model- Driven Engineering(MDE) is an approach to software development where models > programs
Pros: abstraction, and cheaper
Cons: May not be right for implementation, Need translators
MODEL DRIVEN ARCHITECTURE (MDA): general approach to MDE.
TYPES:
(CIM) Computation independent model
(PIM) Platform independent model
(PSM) Platform specific model s
Agile methods with MDA: can be used with agile methods because it is iterative. Can be automated and no separate coding required
