Software and Software Engineering

Overview

 Software is designed and built by software engineers.

 Software is used by virtually everyone in society.
 Software engineers have a moral obligation to build reliable software that
does no harm to other people.
 Software engineers view computer software, as being made up of the
programs, documents, and data required to design and build the system.
 Software users are only concerned with whether or not software products
meet their expectations and make their tasks easier to complete.

Important Questions for Software Engineers

 Why does it take so long to get software finished?

 Why are development costs so high?
 Why can’t we find all errors before we give the software to our customers?
 Why do we spend so much time and effort maintaining existing programs?
 Why do we continue to have difficulty in measuring progress as software is
being developed?

Software

 Software is both a product and a vehicle for delivering a product (information).

 Software is engineered not manufactured.
 Software does not wear out, but it does deteriorate.
 Industry is moving toward component-based software construction, but most
software is still custom-built.

Software Application Domains

 System software
 Application software
 Engineering or Scientific Software
 Embedded software
 Product-line software (includes entertainment software)
 Web-Applications
 Artificial intelligence software

New Software Challenges

 Open-world computing
o Creating software to allow machines of all sizes to communicate with
each other across vast networks
 Netsourcing
o Architecting simple and sophisticated applications that benefit targeted
end-user markets worldwide
 Open Source
o Distributing source code for computing applications so customers can
make local modifications easily and reliably

Reasons for Legacy System Evolution

 Software must be adapted to meet needs of new computing environments or

technology
 Software must be enhanced to implement new business requirements

1
 Software and Software Engineering

 Software must be extended to make it interoperable with more modern

system components
 Software must be re-architected to make it viable within a network
environment

Unique Nature of Web Apps

 Network intensive
 Concurrency
 Unpredictable load
 Availability (24/7/365)
 Data driven
 Content sensitive
 Continuous evolution
 Immediacy (short time to market)
 Security
 Aesthetics

Software Engineering Realities

 Problem should be understood before software solution is developed

 Design is a pivotal activity
 Software should exhibit high quality
 Software should be maintainable

Software Engineering

 Software engineering is the establishment of sound engineering principles in

order to obtain reliable and efficient software in an economical manner.
 Software engineering is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of
software.
 Software engineering encompasses a process, management techniques,
technical methods, and the use of tools.

Generic Software Process Framework

 Communication (customer collaboration and requirement gathering)

 Planning (establishes engineering work plan, describes technical risks, lists
resources required, work products produced, and defines work schedule)
 Modeling (creation of models to help developers and customers understand
the requires and software design)
 Construction (code generation and testing)
 Deployment (software delivered for customer evaluation and feedback)

Software Engineering Umbrella Activities

 Software project tracking and control (allows team to assess progress and
take corrective action to maintain schedule)
 Risk management (assess risks that may affect project outcomes or quality)
 Software quality assurance (activities required to maintain software quality)
 Technical reviews (assess engineering work products to uncover and remove
errors before they propagate to next activity)
 Measurement (define and collect process, project, and product measures to
assist team in delivering software meeting customer needs)
 Software configuration management (manage effects of change)

2
 Software and Software Engineering

 Reusability management (defines criteria for work product reuse and

establish mechanisms to achieve component reuse)
 Work product preparation and production (activities to create models,
documents, logs, forms, lists, etc.)

Attributes for Comparing Process Models

 Overall flow and level of interdependencies among tasks

 Degree to which work tasks are defined within each framework activity
 Degree to which work products are identified and required
 Manner in which quality assurance activities are applied
 Manner in which project tracking and control activities are applied
 Overall degree of detail and rigor of process description
 Degree to which stakeholders are involved in the project
 Level of autonomy given to project team
 Degree to which team organization and roles are prescribed

Essence of Practice

 Understand the problem (communication and analysis)

 Plan a solution (software design)
 Carry out the plan (code generation)
 Examine the result for accuracy (testing and quality assurance)

Understand the Problem

 Who are the stakeholders?

 What functions and features are required to solve the problem?
 Is it possible to create smaller problems that are easier to understand?
 Can a graphic analysis model be created?

Plan the Solution

 Have you seen similar problems before?

 Has a similar problem been solved?
 Can readily solvable subproblems be defined?
 Can a design model be created?

Carry Out the Plan

 Does solution conform to the plan?

 Is each solution component provably correct?

Examine the Result

 Is it possible to test each component part of the solution?

 Does the solution produce results that conform to the data, functions, and
features required?

Software Practice Core Principles

1. Software exists to provide value to its users

2. Keep it simple stupid (KISS)
3. Clear vision is essential to the success of any software project

3
 Software and Software Engineering

4. Always specify, design, and implement knowing that someone else will have
to understand what you have done to carry out his or her tasks
5. Be open to future changes, don’t code yourself into a corner
6. Planning ahead for reuse reduces the cost and increases the value of both
the reusable components and the systems that require them
7. Placing clear complete thought before any action almost always produces
better results

Software Creation

 Almost every software project is precipitated by a business need (e.g. correct

a system defect, adapt system to changing environment, extend existing
system, create new system)
 Many times an engineering effort will only succeed if the software created for
the project succeeds
 The market will only accept a product is the software embedded within it
meets the customer’s stated or unstated needs

4
 Process Models

Overview

 The roadmap to building high quality software products is software process.

 Software processes are adapted to meet the needs of software engineers and
managers as they undertake the development of a software product.
 A software process provides a framework for managing activities that can
very easily get out of control.
 Modern software processes must be agile, demanding only those activities,
controls, and work products appropriate for team or product.
 Different types of projects require different software processes.
 The software engineer's work products (programs, documentation, data) are
produced as consequences of the activities defined by the software process.
 The best indicators of how well a software process has worked are the
quality, timeliness, and long-term viability of the resulting software product.

Software Process

 Framework for the activities, actions, and tasks required to build high quality
software
 Defines approach taken as software is engineered
 Adapted by creative, knowledgeable software engineers so that it is
appropriate for the products they build and the demands of the marketplace

Generic Process Framework

 Communication
 Planning
 Modeling
 Construction
 Deployment

Umbrella Activities (applied throughout process)

 Software project tracking and control

 Risk management
 Software quality assurance
 Formal technical reviews
 Measurement
 Software configuration management
 Reusability management
 Work product preparation and production

Process Flow

 Describes how each of the five framework activities, actions, and tasks are
organized with respect to sequence and time
 Linear process flow executes each of the framework activities in order
beginning with communication and ending with deployment
 Iterative process flow executes the activities in a circular manner creating a
more complete version of the software with each circuit or iteration
 Parallel process flow executes one on more activities in parallel with other
activities

Task Sets

1
 Process Models

 Each software engineering action associated with a framework activity can be

represented by different task sets
 Small one person projects do not require task sets that are as large and
detailed as complex projects team oriented project task sets
 Task sets are adapted to meet the specific needs of a software project and
the project team characteristics

Process Patterns

 Templates or methods for describing project solutions within the context of

software processes
 Software teams can combine patterns to construct processes that best meet
the needs of specific projects

Process Pattern Template

 Meaningful pattern name
 Forces (environment in which the pattern is encountered and indicators that
make problems visible and affect their solution)
 Type
o Stage patterns (define problems with a framework activity for the
process)
o Task patterns (define problems associated with engineering action or
work task relevant to successful software engineering practice)
o Phase patterns (define the sequence or flow of framework activities
that occur within a process)
 Initial context (describes conditions that must be present prior to using
pattern)
o What organizational or team activities have taken place?
o What is the entry state for the process?
o What software engineering or project information already exists?
 Solution (describes how to implement pattern correctly)
 Resulting context (describes conditions that result when pattern has been
implemented successfully)
o What organization or team activities must have occurred?
o What is the exit state for the process?
o What software engineering information of project information has been
developed?
 Related patterns (links to patterns directly related to this one)
 Known uses/examples (instances in which pattern is applicable)

Process Assessment and Improvement

 Standard CMMI Assessment Method for Process Improvement (SCAMPI)

provides a five step process assessment model that incorporates five phases
(initiating, diagnosing, establishing, acting, learning)
 CMM-Based Appraisal for Internal Process Improvement (CBAIPI) provides
diagnostic technique for assessing the relative maturity of a software
organization
 SPICE (ISO/IE15504) standard defines a set of requirements for process
assessment
 ISO 9001:2000 for Software defines requirements for a quality management
system that will produce higher quality products and improve customer
satisfaction

Prescriptive Process Models

2
 Process Models

 Originally proposed to bring order to the chaos of software development

 They brought to software engineering work and provide reasonable guidance
to software teams
 They have not provided a definitive answer to the problems of software
development in an ever changing computing environment

Software Process Models

 Waterfall Model (classic life cycle - old fashioned but reasonable approach
when requirements are well understood)
 Incremental Models (deliver software in small but usable pieces, each piece
builds on pieces already delivered)
 Evolutionary Models
o Prototyping Model (good first step when customer has a legitimate need,
but is clueless about the details, developer needs to resist pressure to
extend a rough prototype into a production product)
o Spiral Model (couples iterative nature of prototyping with the controlled
and systematic aspects of the Waterfall Model)
 Concurrent Development Model (concurrent engineering - allows software
teams to represent the iterative and concurrent element of any process
model)

Specialized Process Models

 Component-Based Development (spiral model variation in which

applications are built from prepackaged software components called
classes)
 Formal Methods Model (rigorous mathematical notation used to specify,
design, and verify computer-based systems)
 Aspect-Oriented Software Development (aspect-oriented programming -
provides a process for defining, specifying, designing, and constructing
software aspects like user interfaces, security, and memory management
that impact many parts of the system being developed)

Unified Process

 Use-case driven, architecture centric, iterative, and incremental software

process
 Attempts to draw on best features of traditional software process models and
implements many features of agile software development
 Phases
o Inception phase (customer communication and planning)
o Elaboration phase (communication and modeling)
o Construction phase
o Transition phase (customer delivery and feedback)
o Production phase (software monitoring and support)

Personal Software Process (PSP)

 Emphasizes personal measurement of both work products and the quality of

the work products
 Stresses importance of indentifying errors early and to understand the types
of errors likely to be made
 Framework activities
o Planning (size and resource estimates based on requirements)
o High-level design (external specifications developed for components
and component level design is created)

3
 Process Models

o High-level design review (formal verification methods used to uncover

design errors, metrics maintained for important tasks)
o Development (component level design refined, code is generated,
reviewed, compiled, and tested, metric maintained for important tasks
and work results)
o Postmortem (effectiveness of processes is determined using measures
and metrics collected, results of analysis should provide guidance for
modifying the process to improve its effectiveness)

Team Software Process

 Objectives
o Build self-directed teams that plan and track their work, establish
goals, and own their processes and plans
o Show managers how to coach and motivate their teams and maintain
peak performance
o Accelerate software process improvement by making CCM Level 5
behavior normal and expected
o Provide improvement guidance to high-maturity organizations
o Facilitate university teaching of industrial team skills
 Scripts for Project Activities
o Project launch
o High Level Design
o Implementation
o Integration and system testing
o Postmortem

Process Technology Tools

 Used to adapt process models to be used by software project team

 Allow organizations to build automated models of common process
framework, task sets, and umbrella activities
 These automated models can be used to determine workflow and examine
alternative process structures
 Tools can be used to allocate, monitor, and even control all software
engineering tasks defined as part of the process model