• Process of creating application to include security measures to protect integrity of data & application itself.
• Develop system to track and control changes
• includes code sets, design documents, testing

1. Project Initiation
2. Functional design analysis & planning
3. System Design specifications
4. Sofware Development
5. Installation/Implementation
6. Operational/maintenance
7. Disposal

• 1st phase of SLC
• researching needs/feasibility of project
• obtain mgt approval to continue SW development

• 2nd Phase of SLC
• Determine functions during project
• preparing project plan

• 3rd Phase of SLC
• Detailed design of SW

• 4th Phase of SLC
• Programming, testing of SW modules as developed

• 5th phase of SLC
• Quality Assurance Team evaluates SW
• User training
• Installation on mgt approval

• 6th Phase of SLC
• continual operation/maintenance of SW
• changes go through change control process

• 7th Phase in SLC
• Terminating Use of SW
• Disposing system
• Security applied during/after disposal phase (ensure information in SW is secured)

• Proprietary: developed by org; source code not disclosed; black box security - validated by testing, but no code inspection -> undisclosed/unexpected vulnerabilities
• Open source: sold w/source code.  Code can be examined; will not fully discover all vulnerabilities, but purchaser can instead of  trusting vendor

1. Define process phases/steps
2. Estimate phase/step time duration
3. Create acceptance step @ end of each phase (aka MILESTONE)
4. Continued/repeating phase (current or previous) if eval fails

• can get stuck @ step before moving onto next step

1. Continuous Risk Analysis
2. Create stepped-out req/specs
3. Develop SW from start to finish (prototype to completed product)
4. Est. full SW development team w/users
5. Alleviate unecessary backtracking by going through cycle again (creates upgrades/SW updates)

• SLIM: Software Life Cycle Model
• COCOMO
  
• SLOC

1. Feasibility
2. Functinoal Specs
3. SW Development
4. Maintenance

1. Effort (E) in months
2. Development (D) in months
3. Estimated # of Lines of Code (KLOC) # in 1000s
4. People (P) # of people to code

(# Estimated code lines) * (cost of code production)

Problem: based on skill level/XP of programmers

• Outputs
• Inquiries
• Inputs
• Files
• Interfaces

1. Initial
2. Managed
3. Defined (most org. target)
4. Quantitatively Managed
5. Optimizing

process improvement proj. initative to incorp. different CMMs into 1 cohesive collection of models:

• system engineering
• SW engineering
• integrated product/process development

1. Request
2. Approve
3. Document
4. Test/Report Results
5. Implement
6. Report

1. Config ID
2. Config Change control (change mgt)
3. Config status accting
4. Config verification/auditing

Config ID

Config Change control (change mgt)

Config status accting

Config verification/auditing

• Do configs in use match configs found in CMS?
• Any unauth/untracked modifications been made?
• Security risks associated w/unauthorized changes?

• Primitive
  
• Array
  
• List
  
• Matrix
  
• Database
  

Primitive

• Data Element
• Singular
• iie. integer, string, bit, byte, octet,dates

Array

List

Matrix

Database

• AI
• Knowledge Base (KB)
• Expert (AI + KB)

• data definition lang
• query lang (iie SQL)
• indexes/keys for effcient access (table of contents)
• security structure (who can access/update DB)
• bult-in bonds/limit checking (standardized format iie Character Limit)
• enforcement of data content rules w/in DB (constraints of inputted data iie. type of data inputted vs. type of data required - alphanumeric vs numeric)
• internal integrity checks (system checks along w/DB checks)

• Hierarchical DB Mgt Model
• Network DB Mgt Model
• Relational DB Mgt Model
• Object Oriented Programming (OOP) Model

• uses pointers to other DB elements

• designer creates relationships btw DB components
• Multiple tables defined
• Table relationships defined

• data stored in container called objects
• limited control
• objects define what is accessed and who accesses it

1. Open Database Connectivity (ODBC): allows std application program interface (API) to connect (MS/SQL std)
2. Java Database Connectivity (JDBC): allows Java-based programs to access DB
3. eXtensible Markup Lang (XML): simplifies presentation in various formats
4. Object Linking & Embedding DB (OLE DB):  allows linking/embedding of docs/graphics/sound into parent doc

1. Table:  set of rows/columns containing related info
2. Tuple:  row/recrod in DB
3. Attribute:  column/field in DB
4. Cell:  aka value; intersection of tuple and attribute
5. Key (aka Primary Key):  attribute that provides UNIQUE value in row
6. Foreign Key:  value that refers to KEY in different table (provides relationship btw tables)

• collection of mult. tables that are related (through use of foreign keys)
• uses normalization
• reduces redundant information
• minimize # rows/columns in tables

• Class category
• Object type
• Modularity object does everything itself;
• Method object's abilities
• Encapsulation hides details of class hidden from object
• Abstraction generalizes classes to highest/most appropiate level for needed use
• Polymorphism classes are equal, referred to in identical terms

1. Atomicity guarantee that all tasks assoc. w/transaction are completed. all or nothing.
2. Consistency DB stability before a transaction can occur
3. Isolation transactions/DB processes cannot see what other transactions/processs are doing. work independently
4. Durability transaction maintains stability during; doesnt break down once completed

• ensures data stored in DB is accurate/valid, not unknowingly altered/deleted
• ACID

• ensures key references are internall consistent
• so when referencing keys, index will be have correct key references

• pre-processed DB
• contains info on specific subject
• used for reporting/analysis
• cannot be updated
• updates put into new data warehouse
• iie. Voter Info

• practice of analyzing large amount of data for previously unknown/hidden info using:
  
  • Interference reviews data trends to make predictions
  • Aggregation summary of info found

1. Access control bypass DBAs bypassing application security = unaudited/edited changes
2. Aggregation unauth release of info
3. Improper view restrictions unauth access to DB due to improperly configured AC
4. DoS improper queries cause system to crash; thorough search on massive DB. affects unavailabilities
5. Deadlocks one user's transaction locks out other users from accessing DB

1. Lock Controls controls who/what can be accessed (userid/pw)
2. Other DBMS access controls view-based, grant & revoke, security for OODB
3. Metadata controls control access to Master DB
4. Data contamination controls peform data validation: checking data typing/length, bounds, well-formed transactions
5. OLTP controls online transaction processing: batch vs single process - race condition; related to concurrency & atomicy