Lesson 1: ACCOUNTABILITY & ACCESS CONTROL

Access control: Security technique that can be used to regulate who or 3. Role based access control (RBAC)
what can view or use resources.1``1````````  Is a widely used – and dominant – access control models, and
most security products available in the market today are based on
Model for Access Control: this model because its objectives are architectural.
Sample Diagram:
SUBJECT OPERATIONS (ACCESS) OBJECT

ACCESS CONTROL MODELS

1. Discretionary Access Control (DAC)

 Access is governed by the access rights granted to the user or user
groups.
Sample Diagram:

Grant Access
OWNER EMPLOYEE ACCESS CONTROL TECHNIQUES

1. RESTRICTED USER INTERFACE

 Menu – only the functions that the administrator wants a user to
be able to perform.
 Shells – only the commands that the administrator wants a user to
read, write or be able to run will be available in the shell environment.
RESOURCES execute  Database views – database can be configured to only show certain
information to different users, depending upon their credentials
 Physical constrained – only providing a limited keypad or touch
button on the screen.
2. Mandatory access control (MAC)  Encryption – requires a decryption key to unmask sensitive info.
 Information is classified into different categories and each 2. CONTENT-DEPENDENT ACCESS CONTROL
category is assigned a particular security level.  Access to objects or websites can be determined by the sensitivity
Sample Diagram: of the content within the objects.
  Centralized - is based on the concept of all access control queries
being directed to a central point of authentication. The central
authentication system performs the authentication and forwards
the authorization data back to the requesting system.
 Decentralize – configured to multiple authentication system. This
basically means that the access control system is not centralized to
a single computer system or group of systems.

ACCESS CONTROL ADMINISTRATION

 Account Administration – administration of all user, system,

and service accounts used within the access control system.
 Determining Rights & Permissions - process will ensure that
the data the access control system is meant to protect is
properly secured.
3. CONTEXT-DEPENDENT ACCESS CONTROL  Management of Access Control Objects - ensuring secure
 Access to objects or a web site can be determined by the sequence storage, applying appropriate security controls, ensuring
of events that preceded the access attempt. proper classification and declassification, and ensuring secure
Sample: data destruction.
 Monitoring - constant monitoring of all security and audit
“Limited trials in forgot password” logs within the system.

4. ACCESS CONTROL MATRIX

 A capability table specifies the access rights a certain subject
possess pertaining to specific objects.

Sample Matrix:

METHODOLOGIES OF ACCESS CONTROL

 Lesson 2: SYSTEM MAINTENANCE MAINTAINABILITY FACTORS

SOFTWARE LIFE - Once a software is developed, its enters a cycle of being used  Availability of qualified staff
and modified that continues for the rest of the software’s life.
 Understandable system structure
WHAT IS SOFTWARE MAINTENANCE?
 Use of standardized programming languages and operating systems.
 Once we deploy our product, our job is still not finished.
 Standardized structure of documentation
 We and/or our customers are probably going to want to make some
 Availability of test cases
changes and improvements to the product.
 Built-in debugging facilities
 This is what we refer to as software maintenance. If we plan for
maintainability all the way through the development cycle, we can make  Availability of a proper computer to conduct maintenance
our job much easier when we are in the maintenance phase.
MAINTENANCE PROBLEMS

 Developer not available.

Maintenance is a good thing. “
 Proper documentation doesn’t exist
 You won’t have to do maintenance if no one uses your product.
 Not designed for change
 If your product is used, users will ask for improvements.
 Maintenance activity not highly regarded
 The more successful products have high maintenance budgets.
“ SOFTWARE RE-ENGINEERING

TYPES OF MAINTENANCE  Re-organizing and modifying existing software systems to make them
more maintainable.
 Perfective maintenance
WHEN TO RE-ENGINEER
Adding or modifying the system’s functionality to meet new
requirements.  When hardware or software support becomes obsolete

 Adaptive maintenance  When tools to support re-structuring are available

Changing a system to adapt it to new hardware or operating RE-ENGINEERING ADVANTAGES

system, such as database upgrades, OS upgrades, compiler
version changes etc.
 Corrective maintenance
Changing a system to fix coding, design or requirements error.
 Reduced risk
There is a high risk in new software development.
There may be development problems, staffing problems and
specification problems.
  Reduced cost  Analysis software with a view to understanding its design and
specification
The cost of re-engineering is often significantly less than the costs
of developing new software.  May be part of a re-engineering process but may also be used to re-
specify a system for re-implementation
BUSINESS PROCESS RE-ENGINEERING
REVERSE ENGINEERING PROCESS
 Concerned with re-designing business processes to make them more
responsive and more efficient.

FORWARD ENGINEERING & RE-ENGINEERING

RE-ENGINEERING PROCESS

REVERSE ENGINEERING
Lesson 3: ESTIMATION FOR SOFTWARE PROJECTS THE PROJECT PLANNING PROCESS

The objective of software project planning is to provide a framework that

enables the manager to make reasonable estimates of resources, cost, and
schedule. In addition, estimates should attempt to define best-case and worst-
case scenarios so that project outcomes can be bounded. Although there is an
inherent degree of uncertainty, the software team embarks on a plan that has
been established as a consequence of these tasks. Therefore, the plan must be
adapted and updated as the project proceeds. In the following sections, each of
the actions associated with software project planning is discussed.

OBSERVATION ON ESTIMATION

Planning requires you to make an initial commitment, even though it’s

likely that this “commitment” will be proven wrong. Whenever estimates are
made, you look into the future and accept some degree of uncertainty as a matter
of course. To quote Frederick Brooks [Bro95]:

Estimation of resources, cost, and schedule for a software engineering

effort requires experience, access to good historical information (metrics), and the
courage to commit to quantitative predictions when qualitative information is all
that exists. Estimation carries inherent risk,1 and this risk leads to uncertainty.
SOFTWARE SCOPE & FEASIBILITY

SOFTWARE PROJECT ESTIMATION

Software cost and effort estimation will never be an exact science. Too
many variables—human, technical, environmental, political—can affect the
ultimate cost of software and effort applied to develop it. However, software
project estimation can be transformed from a black art to a series of systematic
steps that provide estimates with acceptable risk.

SOFTWARE SCOPE & FEASIBILITY

Software scope describes the functions and features that are to be

delivered to end users; the data that are input and output; the “content” that is
presented to users as a consequence of using the software; and the performance,
constraints, interfaces, and reliability that bound the system.

Scope is defined using one of two techniques:

1. A narrative description of software scope is developed after

communication with all stakeholders.

2. A set of use cases 3 is developed by end users.