Software Life Cycle

cockeysvilleuterusΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

150 εμφανίσεις

Enterprise Software Engineering
&
Software Engineering in the
Enterprise
Software Life Cycle
SOFTWARE USAGE AND
DELIVERY
2
3
The Open Process
forgotten
Application Management
4
Different Estimations of the
Development/Maintenance Life-cycle Cost Ratio
5
95 %
5 %
40 %
60 %
80 %
20 %
1 – Estimated average in the IT
industry
2 – A real scenario
3 – Estimated by an software
developer in software house
maintenance
development
1 32
Application Management
6
Release as „End Game“
7
Continuous Delivery
8
Continuous Delivery
9
Kanban Delivery:
Delivery by MMF
10
Delivery team
Customer
PORTFOLIOS
11
12
Process for Ventures
• Venture "An intention to achieve desired effects; initiated by
business planning or external requirements, and accomplished by
the implementation of changes in our business“
• Project"An activity that is limited by time, cost and scope, of one-off
nature, and has a predetermined goal which as a result shall set the
right conditions for desired effects of the related venture“
• Program"A bundle of ventures, whereby each venture has its own
business case, but all ventures are part of a common strategy"
Tools, Technology, Training and Knowledge Transfer
Tools, Technology, Training and Knowledge Transfer
Alignment
Alignment
with Business
with Business
Objectives
Objectives
Integrated
Integrated
Delivery
Delivery
Framework
Framework
Real
Real
-
-
time Executive
time Executive
Decision Support
Decision Support
Collaboration
Collaboration
and Project
and Project
Management
Management
Portfolio
Portfolio
Management
Management
Programs, Initiatives
Programs, Initiatives
Business
Business
Strategy
Strategy
Investment, Resource and
Investment, Resource and
Prioritization Decisions
Prioritization Decisions
Integrated Portfolio of
Integrated Portfolio of
Managed Projects
Managed Projects
Consistent, Repeatable
Consistent, Repeatable
Project Delivery
Project Delivery
Enterprise
Enterprise
Resource
Resource
Management
Management
Projects
Projects
Portfolio Management:
Aligning Initiatives To Strategy
Project Portfolio Management vs.
Project Management
The Project Portfolio Management Process
Context of Organization
Inventorization
Analysis & Assessment
Determination of Portfolio
Implementation
Mission, Goals, Objectives, Culture,
Structure and Infrastructure, Pro-
cesses, Environment etc.
Comprehensive listing of all active,
on-hold and proposed projects at all
levels of the organization.
Multiple Assessment Criteria, Quali-
tative & Quantitative Tools, Software
Applications etc.
Maintain “balance” of projects to
create “optimal mix” based on their
cost, return, risk, schedule etc..
Periodically review and modify port-
folio by retaining, modifying and
(when necessary) killing projects.
15
Governing the Portfolio
16
ARCHITECTURE
No Comment
18
Can be built by one person
Requires
Minimal modeling
Simple process
Simple tools
Architecting a Dog House
Architecting a House
Built most efficiently and timely by a team
Requires
Modeling
Well-defined process
Power tools
Architecting a Sky Rise
22
Architecture Force
23
Architecture vs. Design
Decisions
“Design” decisions
Architectural decisions
“Requirements constraints”
A choice that is binding in the final product
Software
design
Code etc.
Software
Architecture
Requirements
Architecture vs. Design
non-functional
requirements
(“ilities”)
functional
requirements
(domains)
Important : this is a general guideline
Important : this is a general guideline


sometimes the borders are blurred
sometimes the borders are blurred
Architecture:
Architecture:
where non
where non
-
-
functional decisions are cast, and
functional decisions are cast, and
functional requirements are partitioned
functional requirements are partitioned
Design:
Design:
where functional requirements are accomplished
where functional requirements are accomplished
architecture
architecture
design
design
Stakeholders & Their Concerns
Ease of Integration
Ease of Integration
Ease of Use
Ease of Use
Functionality
Functionality
Price
Price
Dev Costs
Dev Costs
On Time Delivery
On Time Delivery
Performance
Performance
Stability & Maintainability
Stability & Maintainability
Ease of Debugging
Ease of Debugging
Modifiability
Modifiability
Testability & Traceability
Testability & Traceability
Structure & dependency between component
Structure & dependency between component
Ease of Installation
Ease of Installation
End User
End User
Sales
Sales
Dev Manager
Dev Manager
Developer
Developer
Sys Admin
Sys Admin
Maintainer
Maintainer
Customer
Customer
26
Architecture Views
• Business artefacts
– events
– processes
– activities
– roles
– rules
– data & documents
– audit trails
– performance indicators
– services
• Technical artefacts
Numerous Enterprise Artefacts
27
KPIs
Processes
Services
Events
Roles
Data
structures
Documents
Rules
Human
“workflow”
Audit
trails
• Dynamic set of artefacts
• Artefacts are interconnected and interdependent
• We have to anticipate potential changes:
– policies, compliance, technology, etc.
• Implementation of such changes
necessitates the evolution of some
artefacts and the relationships
between them
• It must be easy to modify all artefacts
and relationships without causing any
negative effects
System Architecture View of an Enterprise
28
– top managers
– enterprise architects
– business line managers
– process owners
– super-users
– normal users
– project managers
– business analysts
– IT managers
– IT architects
– IT developers
Many Internal Stakeholders
29
Enterprise Architecture is About Building
Representations of the Business
30
What does it Tell you?
Solution Architecture and EA
Solution
Solution
33
Learn from the “other” Culture
• Agilists
– Exploit architecture to scale up
– Exploit architecture to partition the work
– Exploit architecture to communicate
– …
• Architects
– Exploit iterations to experiment
– Exploit functionality to assess architecture
– Exploit growing system to prune (KISS), keep it lean
– …
34
Enterprise Architecture:Growing Pains
We all learn from it
IT SERVICE MANAGEMENT
36
The Challenge -
Aligning IT to the Business
Business Units IT Department
© ProActive
Service
Desk
Customers
Service Level Agreements (SLA’s)
Service Level
Requirements
Service Level
Management
Business
Plans
IT
Planning
37
IT Service Processes
Service Level
Management
Planning
Availability, Capacity,
Continuity and Finance
Infrastructure
Change, Release and
Configuration Management
Support
Service Desk, Incident,
and Problem
Management
Business
Requirements
Budget
Performance
Disaster
Charges
Costs
Performance
Recovery
Charges
Changing or
improving the IT
Infrastructure
Service level
targets
SLA
SLA
38
Service Delivery Processes
Business
Stakeholders
Service Level Management
Capacity
Management
Financial
Mgt
Availability
Management
IT Service
Continuity
Change Management
39
Service Support Processes
Service Desk
Incident Management
Problem
Management
Change
Management
Release Management
Infrastructure
Configuration
Management
Customers
Alerts
40
The ITIL v2 Processes
Service Delivery
Service Level Management
Availability Management
Capacity Management
Financial Management
IT Service Continuity
Management
Service
Desk
From Service Desk to Change Management
41
Service
Desk
Uptime Optimum
42
ITIL VERSION 3
(2007)
44
• Service Strategy
• Service Design
• Service Transition
• Service Operation
• Continual Service Improvement
45
Service
Strategy
Service
Design
Service
Transition
Service
Operation
Continual Service
Improvement
Solutions
Policies Resource Constraints
Business Requirements
Architectures
Standards
Transition Plans
Testing
Operational Plans
Operational services
ITIL v3
The Service Lifecycle
46
47
The Service Lifecycle
Continual
Service
Improvement
48
The Deming Cycle
Continual Improvement
through
Continuous Quality Control
49
ITIL v3
Service Full Lifecycle
Strategic
Approach
Well Defined 7-Step
Improvement Process
Well Defined Implementation
Methodology
ITIL 2011
51
ITIL 2011
• ITIL 2011 is an update, not a new version.
• No entirely new concepts have been
added, but the aim of the update is to
"resolve errors and inconsistencies in the
text and diagrams across the whole suite”.
52
ITIL 2011
• There are a few new
processes, while
others are described
in greater detail.
SECURE SOFTWARE
ENGINEERING
2
8
No comment
No comment
17
Attack Sophistication vs.
Intruder Technical Knowledge
High
Low
1980 1985 1990 1995
2000
password guessing
self-replicating code
password cracking
exploiting known vulnerabilities
disabling audits
back doors
hijacking
sessions
sweepers
sniffers
packet spoofing
GUI
automated probes/scans
denial of service
www attacks
Tools
Attackers
Intruder
Knowledge
Attack
Sophistication
“stealth”/ advanced
scanning techniques
burglaries
network mgmt. diagnostics
distributed
attack tools
Cross site scripting
Staged
attack
1994 (Virus=local problem)
1995 (Globalization)
1999 (Epidemics)
TODAY:Flash
Infected
systems
Seconds Minutes Days Weeks
Months
Future Threats
Involve
Fortress Mentality
Fortress Mentality
Fortress
Fortress
Mentality
Mentality
66
The Weak Link
C
ompare:
Peace Time and War Time
Medical Services
68
Compare:
Peace Time and War Time
Information/Cybersecurity
2
69
SECURITY ARCHITECTURE
What is Security Architecture?
71
Why do Security Architecture?
72
Environment Forces
73
Business Challenge
74
Value of Security Architecture
75
Incorporating Security into EA
76
Enterprise Archirecture
Domains Revisited
77
Enterprise Security Architecture
78
EA Security Architecture
Roadmap
79
Security Architecture Models
80
SECURITY LIFECYCLE
82
Definition of Secure
A secure product is one that protects the
confidentiality, integrity, and availability of the
customers’ information, and the integrity and
availability of processing resources under
control of the system’s owner or
administrator.
-- Source: Writing Secure Code (Microsoft.com)
83
How much Security do we Need?
Complexity vs.Security
As Functionality and
hence complexity
increase security
decreases.
Integrating security into
functionality at design time 
Is easier and cheaper.
“100 Times More Expensive to Fix 
Security Bug at Production Than Design”
– IBM Systems Sciences Institute
It also costs less in the long‐term.
‐maintenance cost
84
Software Security
• Software security—the process of
designing, building, and testing software
for security.
• Software security practitioners attempt to
build software that can withstand attack
proactively.
85
Security as an Attribute
“Security just another of software like
usability, performance, reliability,
scalability.
The idea of incorporating security into
the SDLC begins with evaluating the
relative importance of this attribute
and then going on to incorporating
controls in line with that.”
86
Security Lifecycle (1)
87
Security Lifecycle (2)
Architectural Risk Analysis
88
System Assurance:
Model or Code ?
89
Evil User Stories
90
Evil User Stories
91
Misus
e
Cases
92
CLASP – Comprehesive, Lightweight
Application Security Process
– An activity-driven, role based set of
process components whose core contains
formalized best practices for building security
into your existing or new-start software
development lifecycles in a structured,
repeatable, and measurable way.
93
CLASP
Views
94
AGILE SECURE SOFTWARE
ENGINEERING
Agile Security? – The Devil’s Advocate
97
The Agile Practitioner’s
Dilemma
Agile Forces:
More responsive to
business concerns
Increasing the
frequency of stable
releases
Decreasing the
time it takes to
deploy new
features
Secure Forces:
More aggressive
regulatory
environment
Increasing focus on
need for security
Traditional
approaches are
top-down,
document centric
Microsoft Security Development
Lifecycle (SDL)
98