YEAR 2 SEMESTER 2
CIR 206: SOFTWARE ENGINEERING
NOTES 1
Introduction
A Definition of Software
• Instructions (computer programs) that when executed provide desired features, function,
and performance
• Data structures that enable the programs to adequately manipulate information
• Documents that describe the operation and use of the programs
Legacy Software – Characteristics
• Support core business functions
• Have longevity and business criticality
• Exhibit poor quality
– Convoluted code, poor documentation, poor testing, poor change management
Reasons for Evolving the Legacy Software
• (Adaptive) Must be adapted to meet the needs of new computing environments or more
modern systems, databases, or networks
• (Perfective) Must be enhanced to implement new business requirements
• (Corrective) Must be changed because of errors found in the specification, design, or
implementation
Basic engineering processes
Software Engineering – Defined
• (1969) Software engineering is the establishment and use of sound engineering principles
in order to obtain economically software that is reliable and works efficiently on real
machines
• (IEEE) The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of
engineering to software
1
,Software Engineering is a Layered Technology
Process, Methods, and Tools
• Process
– Provides the glue that holds the layers together; enables rational and timely
development; provides a framework for effective delivery of technology; forms
the basis for management; provides the context for technical methods, work
products, milestones, quality measures, and change management
• Methods
– Provide the technical "how to" for building software; rely on a set of basic
principles; encompass a broad array of tasks; include modeling activities
• Tools
– Provide automated or semi-automated support for the process and methods (i.e.,
CASE tools)
Generic Process Framework
• Communication
– Involves communication among the customer and other stake holders;
encompasses requirements gathering
• Planning
– Establishes a plan for software engineering work; addresses technical tasks,
resources, work products, and work schedule
• Modeling (Analyze, Design)
– Encompasses the creation of models to better understand the requirements and the
design
• Construction (Code, Test)
– Combines code generation and testing to uncover errors
• Deployment
– Involves delivery of software to the customer for evaluation and feedback
2
,Umbrella Activities
• Software requirements management
• Software project planning
• Software project tracking and oversight
• Software quality assurance
• Software configuration management
• Software subcontract management
• Formal technical reviews
• Risk management
• Measurement – process, project, product
• Reusability management (component reuse)
• Work product preparation and production
What is a Process?
• (Webster) A system of operations in producing something; a series of actions, changes,
or functions that achieve an end or a result
• (IEEE) A sequence of steps performed for a given purpose
What is a Software Process?
• (SEI) A set of activities, methods, practices, and transformations that people use to
develop and maintain software and the associated products (e.g., project plans, design
documents, code, test cases, and user manuals)
• As an organization matures, the software process becomes better defined and more
consistently implemented throughout the organization
• Software process maturity is the extent to which a specific process is explicitly defined,
managed, measured, controlled, and effective
Capability Maturity Model (SW-CMM)
• Developed in 1987 by the Software Engineering Institute (SEI) at Carnegie-Mellon
University under the sponsorship of DARPA
• Described in the book Managing the Software Process in 1989 by Watts Humphrey
• Published as a separate document: Capability Maturity Model for Software in 1991
Immature Software Organizations
• Software processes are generally improvised
• If a process is specified, it is not rigorously followed or enforced
• The software organization is reactionary
• Managers only focus on solving immediate (crisis) problems
• Schedules and budgets are routinely exceeded because they are not based on realistic
estimates
3
, • When hard deadlines are imposed, product functionality and quality are often
compromised
• There is no basis for judging process quality or for solving product or process problems
• Activities such as reviews and testing are curtailed or eliminated when projects fall
behind schedule
Five Levels of Software Process Maturity
Characteristics of Each Level
• Initial Level (Level 1)
– Characterized as ad hoc, and occasionally even chaotic
– Few processes are defined, and success depends on individual effort
• Repeatable (Level 2)
– Basic project management processes are established to track cost, schedule, and
functionality
– The necessary process discipline is in place to repeat earlier successes on projects
with similar applications
• Defined (Level 3)
– The software process for both management and engineering activities is
documented, standardized, and integrated into a standard software process for the
organization
4