CS6231 SWEngineering Lecture 1b SE Introduction

CSCI-6231: Software Engineering
Fall 2023
Jon Walter McKeeby, D.Sc.
Based on Slides by
Stephen H. Kaisler, D.Sc.
Introduction
To
Software Engineering
Lecture 1
CSCI 6231. Software Engineering.
3 Credits.
The life-cycle model. Requirements and

specifications. Design models, structured and
object-oriented design. Program development, PDL’s
tools, configuration control. Program, unit, and
integration testing. Program verification. Other
development models. Development metrics.
Computer-aided software engineering (CASE).
Prerequisites: CSCI 6221 and CSCI 6212. Fall and
Spring, Every year.
Information System
Bourgeois, D. (2019). Information Systems for Business and Beyond.
1: What Is an Information System? - Workforce LibreTexts
• An information system (IS) can be defined technically as a set of

interrelated components that collect, process, store, and distribute
information to support decision making and control in an organization.
• Information systems are combinations of hardware, software, and
telecommunications networks that people build and use to collect, create,
and distribute useful data, typically in organizational settings.
• Information systems are interrelated components working together to
collect, process, store, and disseminate information to support decision
making, coordination, control, analysis, and visualization in an
organization.
09/16/2023 CSCI 6231 - Software Engineering 1-3

Jon W. McKeeby, D.Sc.
Information System
Bourgeois, D. (2019). Information Systems for Business and Beyond.
1: What Is an Information System? - Workforce LibreTexts
Process
Infrastructure
• Networking People
• Hardware
Information
System
Data
Software
Databases

Processes
Development Using Support

• Planning • User Workflows • Service Center Support
• Design • Supervisor Workflows • Updates
• Coding • Executive Workflows • Configuration
• Testing Management
• Training • Change
Management

People
Development Using Support

Project Managers Users Service Center
Architects Stakeholders User Support
System Administrators Executives System Administrators
Database Administrators Database
Network Administrators Administrators
Software Developers Network Administrators
Testers Software Developers
Trainers

Software
• User Devices
User • Connectivity/Network
• Applications
Software • Operating System
• Databases
• Data Warehouses
Data • Files
• Dashboards
• Hardware
Infrastructure • Network

Data versus Information
• Data are raw facts
• Data management: focuses on proper generation,
storage, and retrieval of data
• Data is the foundation of information, which is the
bedrock of knowledge
• Information produced by processing data
• Information requires context to reveal meaning
• Accurate, relevant, timely information is the key to good
decision making
• Good decision making is the key to organizational
survival

Databases
• Databases solve many of the problems encountered in
data management
– Used in almost all modern settings involving data management:
• Business
• Research
• Administration
• Important to understand how databases work and
interact with other applications

Database Management Systems
• Database: shared, integrated computer structure that
stores a collection of:
– End-user data: raw facts of interest to end user
– Transactional data: data pertaining to the domain
– Metadata: data about data
• Provides description of data characteristics and relationships in data
• Complements and expands value of data
• Database Management System (DBMS)
– Manages structure and controls access to data

Database Usage
Coronel, M. (2018). Database Systems: Design, Implementation, and
Management. Edition: 13th .Cengage Learning Book ISBN: 978-1337627900

Database Management System
Coronel, M. (2018). Database Systems: Design, Implementation, and
Management. Edition: 13th .Cengage Learning Book ISBN: 978-1337627900

Information Systems
• Please identify an information system that you use at
work.
• How do you use the information system?
• Who else uses the system?
• How do others use the data?

Information Systems
• What processes does the system support?
• Does the system provide data to other systems?
• Does the data from the system support other processes?

Information Systems
• Think about an eCommerce system that you use.
• How do you use the site?
• What features do you use from the site?
• What do you like about the site? Dislike?

Information Systems
• What would you change about the site?
• After you place your order what happens?

– Who else needs data from the system?
– What other processes does the system need to support?
– What are other ways data from the system can be used?

Introduction
Software Engineering: Definition
• Software Engineering is the establishment and use of sound engineering
principles (methods) in order to economically obtain software that is reliable
and works on real machines.
- F.L. Bauer, 1970
• Software Engineering is about designing and developing high-quality

software.
- S.L. Pfleeger, 1991
• Software engineering is the application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance of
software that is, the application of engineering principles to software.
- IEEE Standard Glossary of Software Engineering Terminology
09/16/2023 CSCI 6231 - Software Engineering 17

A Little Bit of History - I
• Software Engineering term first emerged as title of a
1968 NATO conference:
– The term did not become widely used and recognized in the
software community until the mid-1970’s
– Originated by Watts Humphrey
• 1979: General Accounting Office
– 50% + of contracts had cost overruns
– 60% + of contracts had schedule overruns
– 45% + of software contracted for could not be used
– 29% + of software was paid for and never delivered
– 22% + of software contracted for had to be reworked/modified to
be used

A Little Bit of History - II
"Several factors contributed to the situation [of having software
development problems].
First, the invisible nature of both the work process and its product
made software projects very difficult to manage and predict.
Second, the explosive growth of the use of computers created a
great demand for new programmers, most of whom were self-
taught on the job; and frequently, low productivity and poor
quality resulted.
Third, there was little idea then of how to train programmers
properly.
Fourth, a tradition grew that programmers were secretive
craftspersons whose products, during development, were their
own property. "
A Little Bit of History - III
• MIT/GE/Bell Labs (MULTICS Project)
• IBM OS 360 (Over 1 staff century of labor)
-- Fred Brooks – The Mythical Man Month, 2nd Ed. (See Reference Books)
• 1970s
– Scaling of development efforts was difficult - folklore
– Structured Programming, Chief Programmer Teams – Harlan Mills
– The problems being solved were not well understood (lots of basic research in
operating systems conducted)
– Basic concepts emerged, reuse through libraries, modularity, pathological
coupling (later used in structured design – Glenn Myers)
• 1980s:
– DoD attempts to solve manpower problems by mandating Ada
– In the programming genre, encapsulation and abstract data types emerged
– Serious metrics and whole life cycle methodologies emerged
• 1982 - Tom DeMarco
– 25% of large systems development projects never finished

A Little Bit of History - IV
• 1991 Capers Jones Study
– Average Management Information Systems project is
1 year late and 100% over budget
• 1990s:
– Even cheaper computers, industry settles on C/C++, Academia
uses C++ and moves toward Java, Ada all but dies.
– Software Architecture emerges as an essential concept.
– Industry products developed that incorporated business logic
(the reuse concept that began with subroutines, matured with
abstract data types and object-oriented development) was now
applied to whole areas of business)
– Whole life cycle methods continued, new development concepts
emerge to break the long time frame of the waterfall model –
rapid prototyping, agile development
– Components emerge from middleware

What is Software Engineering?
• Major difference between software engineering and other
types of engineering:
– Other types deal with material (visible and tangible) objects.
– Software is nonmaterial although its effects may be so.
– Software is better viewed as the capturing of a process within a
machine.
• The software engineer is a problem solver.
– The problem, of course, is to build the best system that satisfies
the requirements levied by a customer - within time and resource
constraints.
– Best System -> High Quality -> Solves the Problem(s)
Axiom:
Success is defined by the beholder (user), not the designer!
Software Engineering
• A Problem-Solving Activity:
– Analysis: Understand the nature of the problem and break the
problem into pieces
– Synthesis: Put the pieces together into a coherent structure.
• For problem solving, we use

– Techniques (methods):
• Formal procedures for producing results using some well-defined
notation
– Methodologies:
• Collection of techniques applied across software development and
unified by a philosophical approach
– Tools:
• Manual and Automated systems to accomplish a task

Software Engineering Genealogy
Waterfall Ada
Machine Code
Life-Cycle Alvey Today
Model Top Down SEI Object-Oriented
Structured Esprit Development
Assembly Agile Programming
Language Design
High Order 4GLs
Languages Software Paradigms
Jackson System
Info Transformation Are there 5GLs?
Engineering Paradigm
McCabe's
Complexity Automation Web-based Systems
Metrics Paradigm
NoSQL DBMSs
Structured Chief Reuse
Programming Halstead's Programmer Repositories Language and
Software Team
tool churning
Science Process
Improvement
Production Era
Process Years
Early Years Project Years
1960s 1970s 1980s 1990s 2000s

The Project Years
• Concept of programming evolves from programming-in-the-small to
programming in the many
• Abstraction techniques, such as “top down” structured design, were
introduced
• Programming tools were rather basic: languages, debuggers, simple
documenters
• Testing was largely an art which was done late in the development
cycle
• Project management methods began to emerge
• The most important initiatives in the US were the development of
Ada by the Dept. of Defense and the formation of the Software
Engineering Institute (SEI).

The Process Years - I
• Japanese Software Factory set the standard for producing software
in a highly disciplined environment:
– use of highly trained and concentrated development teams
– application of metrics to measure process improvement and product quality
• Japan’s MITI Fifth Generation Project focused on advancing AI
software, hardware, and applications.
• DARPA’s Strategic Computing Program focused on advancing
technology and demonstrating it in military applications.
• ALVEY Project (UK)/ESPRIT (EU) focus on information technology
development.
• Software Engineering Institute (SEI) at CMU established to advance
software engineering practice and improve quality through five thrusts:
– Software Engineering Process
– Software Engineering Techniques
– Real-Time Distributed Systems
– Software Engineering Education
– Software Risk management

The Process Years - II
• Focus on process improvement led to measurement
practices, definition of a unit of work, gathering of error
data, and metrics development
• Emergence of object-oriented programming
• Emergence of CASE (Computer-Aided Software
Engineering) tools
• Standards established by DoD/NIST/IEEE, especially
MIL-STD-2167A
• Development of Capability Maturity Model (CMM) by SEI

The Production Era
• The era of production quality software development
through near-automation meant:
– emergence of megaprogramming environments (millions of lines
of code)
– more emphasis on abstract descriptions that can be
automatically transformed into working code
– reuse repositories and principles
• Impact of knowledge-based systems as new
programming paradigm
• Development of high integrity software, robust, error-
tolerant, fail-soft (fail-never?), (true) real-time
• Emergence of software safety as a discipline
• Validation and verification as a more precise discipline

Who are the Actors - I?
• Stakeholders: Customers who fund a project or acquire a product to satisfy their
organization’s business objectives.
• Users who interact directly or indirectly with the product (a subclass of customers)
• Requirements analysts who write the requirements and communicate them to the
development community.
• System designers: Persons who design the software according to established
principles.
• System/Software Developers: people who design, implement, and maintain the
product.
• System Testers: people who determine whether the product behaves as intended.
• Documentation writers: people who produce user manuals, training materials, and
help systems.
• Project Managers: people who plan the project and guide the development team to a
successful delivery.
• Installation and Operations Personnel: people who install, operate and administer the
system/software.

The Role of Software Engineering
Customer
Programmer
First law of software engineering

The Software Engineer must be willing to learn the problem domain
(a problem cannot be solved without understanding it first)
Source: Ivan Marsic, Rutgers University

The Role of Software Engineering - II
Customer:
Requires a computer system to achieve some business goals
Source: Ivan Marsic, Rutgers University

by user interaction or interaction with the environment
in a specified manner
System-to-be
Environment
Software-to-be
User
Des
c ribe
s ne e Software Engineer’s task:
d
To understand how the system-to-be needs to interact with
the user or the environment so that customer’s requirement is met
and design the software-to-be
May be the Programmer’s task:

same person To implement the software-to-be
designed by the software engineer

Early Software Development
• One or two people start writing programs, maybe splice them
together – small programs, limited focus

Original Waterfall Model
Requirements Each activity confined to its “phase”.
Unidirectional, no way back;
Design finish this phase before moving to the next
Implementation The Granddaddy of

Software
Development
Testing Methodologies
Waterfall
method Deployment &
Maintenance
Revised Model:
Possibly return to
previous stage to rework
if missing elements

Waterfall Software Development Model
Royce, W. (1970). Managing The Development of Large

Software Systems. IEEE WESCON.
09/16/2023 CS 6231 - Software Engineering 8b-34

Waterfall: Documentation
Royce, W. (1970). Managing The

Development of Large Software Systems.
IEEE WESCON.
Waterfall: Preliminary Program Design

IEEE WESCON.
Waterfall: Plan, Control, Testing

IEEE WESCON.
Waterfall: Critical Software Review

IEEE WESCON.
What We will Do
• Examine the stages of software engineering according to
the Waterfall model to set the stage:
– Stage 0: Conceptualization
– Stage 1: Requirements Engineering
– Stage 2: System Design
– Stage 3: System Development
– Stage 4: System Testing
– Stage 5: System Deployment & Operation
• Later On:
– Examine Agile Methodologies
– Examples of Software flaws
– Take a look at Why Software Projects Fail
– Discuss Issues and Challenges

I. Requirements Engineering Stage
• A user/organization determines the need for a
new/revised software system:
– The requirements for the software system must be elicited from
various stakeholders and analyzed.
– Detailed requirements are specified
• Input:
– Concept of Operations
– System Context and Environment
– Description of user problems and solutions
• Output:
– System Requirements Document (SRD)
– Identification of major data sources, functions, results, and
constraints

Requirements Engineering
• Goal: Produce a System Requirements Document
• Note: Errors made during the Requirements Engineering process often
account for 40 to 60 percent of all defects found in a software project.
NOTE: The use of the term “Engineering” may be somewhat of a misnomer, at
least with the standard definition of Engineering on Wikipedia.

Requirements

What is a Requirement?
• Requirement – an understanding between customer and
supplier
– What the system must do to meet the needs of the customer
– A condition or capability needed by a user to solve a problem or
achieve an objective. (IEEE Standard Glossary)
– A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification, or other formally imposed document. (IEEE
Standard Glossary)

Business Requirements
Business requirements represent high-level objectives of the organization or
customer who requests the system.
They typically come from the funding sponsor of the project. The acquiring
customer, the manager of the actual users, the marketing department, or a
product visionary. (Think Steve Jobs)
Business requirements describe why the organization is implementing the

system.
They represent what the organization is hoping to achieve.
They are often recorded in a document called a Concept of Operations.

Functional Requirements
Functional requirements specify the functionality that the software should have
to satisfy the user’s business operations.
They specify what features the system developers should build into the
product to enable users to accomplish their tasks.
They may be called Behavioral Requirements (although that is out of vogue).
Typically expressed as “shall” statements.

Ex: The system shall email a reservation confirmation to the user after the
reservation is made.”

Non-functional Requirements
Nonfunctional requirements include performance goals and descriptions of
quality attributes.
Quality attributes describe the product’s characteristics in various

dimensions such as the “ilities” that are important to users or developers:
- Usability
- Reliability
- Portability
- Efficiency
- etc…
They also define and describe external interfaces to the real world, and
design and implementation constraints.
Constraints impose restrictions on the choices available to developers for

construction of the product.

Types of “-ilities”
• Security — Does your product store or transmit sensitive
information? Does your IT department require adherence
to specific standards? What security best practices are
used in your industry?
• Capacity — What are your system’s storage
requirements, today and in the future? How will your
system scale up for increasing volume demands?
• Compatibility — What are the minimum hardware
requirements? What operating systems and their
versions must be supported?
• Reliability and Availability — What is the critical failure
time under normal usage? Does a user need access to
this all hours of every day?
Types of “-ilities”
• Maintainability + Manageability—How much time does it
take to fix components, and how easily can an
administrator manage the system? Under this umbrella,
you could also define Recoverability and Serviceability.
• Scalability – The Black Friday test. What are the highest
workloads under which the system will still perform as
expected?
• Usability — How easy is it to use the product? What
defines the experience of using the product?
• Regulatory — Are there requirements you need to satisfy
for compliance?
• Environmental — What types of environments will the
system be expected to perform within?
User Requirements
User requirements describe user goals or tasks that the user must be able to
perform with the product.
Ex: “ I must be able to make a reservation for ….”
Some ways to represent user requirements include:

- Scenarios
- Use cases
- Event response tables
They describe what the user will be able to do with the system, e.g., what tasks
s/he can do.

Requirements Engineering Process- II
• Domain understanding: how the organization operates
internally and with external entities.
• Requirements collection: interaction with stakeholders to
gather requirements
• Classification: grouping requirements into coherent
clusters by function, attribute, entity, etc.
• Conflict resolution: finding & resolving anomalies,
conflicts, and missing data among requirements
• Prioritization: interacting with stakeholders to identify the
most important requirements)
• Requirements checking: assessing completeness,
consistency, real needs, other attributes
• Writing the SRD: Preparing the documentation for the
next stage.
Requirements Engineering Process - I
• Generic Model for Requirements Engineering
• Varies among organizations
Requir ements
definition and
Requirements specification
validation
Domain
Prioritization
understanding
Process
entry
Requirements Conflict
collection resolution
Classification
Source: Suad AlRumani, Introduction to Software Requirements

II. System Design Stage
• A system architecture/design that specifies the software design,
databases, and hardware/networking environments.
• Describes the integration of individual components, modules, and
subsystems that will yield an operational system.
• Input:
– System Requirements Document (SRD)
– System hardware and software environment (optional)
• Output:
– System Design Document (SDD) includes:
• System/Software Architecture
• System/Subsystem Decomposition to 3rd level
• Communications protocols between systems/subsystems – both internal and
external
– Top-level Data Base Design (DBD)
– Top-level design of User Interface

What is a Specification?
• Specification: How the system must do something to (partially) solve the
problem.
– There are many specifications for the system
– Requirement ≠ Specification
• Specifications for the system are developed during the System Design
stage.
During
detailed
design

System Design - I
Functional System Design is the process of architecting the solution to the
problem.
It is the initial translation of the requirements specifications to a set of modules
that describe the system architecture of the proposed solution.
Three key decisions are required:

1. Defining the boundaries along which to decompose the system.
2. Determining into how many pieces to break and their hierarchical or
distributed relationships.
3. Identifying the proper level of detail when design should stop and
implementation should start.
Note: the term “module” has many definitions. Here we use it to describe
subsets of functional requirements specifications that are to be implemented in
an executable entity in the resulting system.

System Design: Top-Down
A decomposition process which focuses on the flow of control or on the
control structure of the program; modules are developed in execution
sequence.
• Details of the design at lower levels are hidden; a module at any

level merely represents the skeleton of the levels below it
• Breadth-first expansion of modules at each level
• Defer decisions as long as possible concerning where crucial
functions will be performed
• A project schedule reflects a continuing integration as part of the
development process because code currently being developed
only on code already operational

System Design: Top-Down Example
Example: Consider the process of solving for and classifying the roots of a
cubic equation: Ax**3 + Bx**2 + Cx + D = 0
Top-down approach:
Roots of
Cubic Equation
|
|
---------------------------------------------------------------------
| | | | |
Input Test for Find Classify Output
Coefficients singular roots roots roots and
A,B,C,D cases classification

System Design: Bottom-Up
One first visualizes a typical system design and decides by
experience, intuition, or quick analysis (guessing?) which
parts of the design are the most difficult or limiting ones
• These crucial parts are investigated first, and necessary

design decisions are made
• The rest of the design is built around these crucial parts
• Make decisions about crucial functions as early as
possible

System Design: Bottom-Up Example
Example: Consider the process of solving for and classifying the roots
of a cubic equation: Ax**3 + Bx**2 + Cx + D = 0
Bottom-up approach:
Output roots
and classification
|
| Note that changing the algorithm to be used may
Classify roots change the entire structure of the bottom-up design
whereas, at most, the only change to be made in the
| top-down algorithm will be to change the nature of
| the box "Find roots"
Use quadratic
formulas <-------------------
| |
| |
Extract real root Input
using Newton's <------ coefficients
method A,B,C,D

Comparing Top-Down vs. Bottom-Up - I
1. Specification
Top-down: Requires well-defined specifications and definition of environment

from end-use
Bottom-up: Work can begin based on detailed specifications only for the crucial
modules
2. Design mistakes
Top-down: If made at a high level and not found until later, they can necessitate
major rewriting. If made at a low level (e.g., early in the design), the impact will
be small. Only a single small module will be affected.
Bottom-up: More tolerant of early errors since they only represent redesign of a
single module in most cases.

Comparing Top-Down vs. Bottom-Up - II
3. Testing
Top-down: Top-down testing requires test stubs but not test drivers.
Bottom-up: Bottom-up testing requires test drivers, but not test stubs.
4. Standardization
Top-down: Where appropriate, standardized structures can be

developed for particular application area.
Bottom-up: Standardized modules can be devised for critical functions

which are often used.

Comparing Top-Down vs. Bottom-Up - III
5. Data structures
Top-down: One can delay details of data structures wholly contained in lower
levels during the initial stages of design.
Bottom-up: One must decide on all data structures which the module interfaces
with before proceeding.
6. Crucial storage problems
Top-down: Both top-down and bottom-up methods must be used; often called
the middle-out approach.
Bottom-up: Best philosophy is to begin bottom-up design only on crucial

storage-related problems in parallel with top-down design for other portions of
software.

Comparing Top-Down vs. Bottom-Up - IV
7. Critical real-time problems
Top-down: Same as item 6.
Bottom-up: Same as item 6. Most real-time problems are tackled bottom-up

because the most critical part of the system are the data acquisition and control
processes.
8. Impact on existing personnel
Top-down: Requires a different approach from that previously used. Can pose a
threat to the less skilled designers and programmers. Not for the "hacker"
mentality.
Bottom-up: Comfortable, with no surprises (with no intellectual challenges in

many cases).

Comparing Top-Down vs. Bottom-Up - V
9. Impact on new personnel
Top-down: Many designers and programmers are now being trained this way. May be a
novel approach to old-timers. Military regulations force many corporations to retrain their
personnel.
Bottom-up: As long as they aren't "computer enthusiasts" who revel in bit juggling and
assembly language tricks, the illogic of poorly chosen bottom-up designs should be clear.
10. Management acceptance
Top-down: It may take time to educate top-level managers about what to expect at
various stages. Structure charts or pseudo-code for all levels of design are completed
first before code is written.
Bottom-up: It is easy to convince top-level managers that you are making progress if you
cite the percentage of code completed (though it is hard to justify just how much must be
written!).

Comparing Top-Down vs. Bottom-Up - VI
11. Module size
Top-down: Limited to one page, 50 lines of pseudo-code or less (not a rigid

limit). If a module takes more pseudo-code, it should be divided into
submodules.
Bottom-up: Size is set by the module being designed. May be very large or very
small.
12. Integration-test problems
Top-down: Usually no serious surprises occur to interrupt the integration phase,

because the interfaces and test procedures are already designed.
Bottom-up: Surprises sometimes occur as integration progresses because

testing reveals interface incompatibility.

Comparing Top-Down vs. Bottom-Up - VII
13. Feasibility
Top-down: If others have completed similar problems (modules), feasibility is proved

and top-down design is recommended.
Bottom-up: If feasibility is in question, a two-stage process is recommended: bottom-up to

prove feasibility; top-down to complete final design and check consistency.
14. Added features
Top-down: Easy to include because they generally represent added modules or redesign
of a few modules, but retain the same control structure. If they can be anticipated, the
test stubs and interfaces can be coded and left in for future use.
Bottom-up: May cause major redesign if interfaces are no longer compatible.

III. System Development Stage
• Expand the system design to a level allowing the implementation of
individual components and modules
• Selection of development tools, DBMS(s), programming
language(s), and already built software (ABS).
• Input:
– System Design Document (SDD)
– Already Built Software documentation
• Output:
– Source/object code for all developed modules
– Source/object code for all ABS modules
– Integration and Build specifications
– Source code documentation
– Possibly, a revised SDD

IV. System Testing Stage
• Functional and end-to-end testing of the integrated system after
developing the test plan to evaluate the system's compliance with its
specified requirements.
• Inputs:
– Source/object code for all developed modules
– Integrated System
– Source code documentation
– Test Data Bases
– System Test Environment (Hardware, Software, Networks)
• Outputs:
– System Test Plan (STP)
– Trace of code modules to requirements
– System Testing Results Document
– Modifications/enhancements to correct errors found in testing
– Performance evaluation results

System Testing
• System Testing is the process of verifying and validating that a
module, subsystem, or system meets its requirements.
• Purpose: to affirm the quality of software systems by

systematically exercising the software in carefully controlled
circumstances.
• Verification: does the component implement the right

requirements
– Initially a subset or all of them
• Validation: does the component implement the requirements
correctly.
• Testing is performed through the controlled execution of the

program with known inputs and outputs (both predicted and
observed), combined with internal measurement of the behavior of
the program.
Types of System Testing
• Static analysis: A program is analyzed without regard
to its run-time behavior.
• Dynamic analysis: A program is executed under
carefully controlled circumstances and its behavior is
studied in many ways.
• A program is well-tested when the program tester has an adequately

high level of confidence that there are no remaining "errors" that
further testing would uncover.
• This does not mean that there are no remaining errors. Part of the
art of testing is to know when to stop.
• System Acceptance Testing is the process of convincing the
customer that a system has the functionality and performs the
functions the customer has requested correctly, timely, and robustly.

V. System Deployment & Operation Stage
• After system testing is complete, the system is deployed
for operation.
• The system is accepted by the customer/client.
• The system enters a maintenance stage.
– This is a misnomer since most projects cannot resist making
“enhancements”
• Inputs:
– System Documentation
• Output(s):
– System Deployment Plan (SDP)
– System Maintenance Plan (SMP)
– Revised System Documentation
• May include SRD, SDD, STP, SDP, SMP

System Deployment, Operation & Maintenance
• Assuming system acceptance testing is successful,
the system must be deployed and also maintained.
• System Deployment is the process of installing the
system on the operational hardware and operating the
system in support of the customer’s business
operations.
• System Maintenance is the correction of “after the
fact” bugs as well as the development of
enhancements based on the latent discovery of new
requirements.
Axiom: All maintenance is a process of continuous

enhancement.

Software Engineering: Issues and Challenges
• There are many issues and challenges in software
engineering.
• We will discuss some of them throughout the course and

in Lecture 13.
• The lectures will cite Eberhardt Rechtin, System

Architecting and The Art of System Architecting a lot.

Practical Side
• Organizations Have Their Own Processes
• Request Management / IT Governance
• Systems Development Life Cycle
• Review a Federal System Development Framework

Request Management
Portfolio Management Office
1. Triage new inbound requests, with representation from:
– Portfolio Office
– Financial Management
2. Develops project charter based on feedback from:
– Requestor and/or Stakeholder(s)
– Technical Architect
– ISSO
– Others, as needed (e.g. Subject Matter Experts, Privacy Office,
etc.)
3. Facilitates all IT-related reviews/approvals
4. Schedules/Assigns projects based on need, priority, and
resource availability
5. Reports on status of pending and active projects

Systems Development Life Cycle
Database Systems:
Design, Implementation,
and Management.
Edition: 13th (2018)
Author: Coronel, Morris
Publisher: Cengage
Learning Book ISBN:
978-1337627900

Jon Walter McKeeby, DSc.
IT Projects
• IT projects have the following distinct characteristics:
– It requires new Software Development
– It requires over 40 hours of staff time to complete, post-analysis
– It is temporary
– It produces a specific and distinguishable product, service or
result
– It is done for a specific purpose
– It has interrelated activities or tasks
– Its definition becomes progressively more detailed as its nature,
components, and outcomes are better understood
• Requests that take less than 40 hours to complete are
considered general Operations & Maintenance (O&M)
and fall under the Configuration Management process.

The Software Development Life Cycle
• Traces history (life cycle) of information system
• Database design and application development mapped
out and evaluated
• Divided into following five phases:
– Planning
– Analysis
– Detailed systems design
– Implementation
– Maintenance
• Iterative rather than sequential process

Waterfall Lifecycle
http://www.bing.com/images/search?
q=waterfall+lifecycle&qpvt=waterfall+lifecyc
le&FORM=IQFRML#view=detail&id=E96B
357E311613453DEAB5A36C3B5E181E20
B02B&selectedIndex=1

HHS EPLC Framework
• HHS OMB has raised the standards for the management
and performance of IT investments within the Federal
government. These standards require an environment of
accountability and project management to ensure IT
projects consistently achieve successful outcomes and
meet cost, schedule and performance objectives
• The purpose of the HHS EPLC framework is:
– Solid project management methodology
– Repeatable processes
– Standard structure for planning, managing and overseeing projects over
their entire lifecycle
• The EPLC framework is followed for all IT projects
An IT project is any project that utilizes a computerized
system

HHS IT Project

HHS EPLC Framework
Waterfall Software Development HHS Enterprise Project Lifecycle
Lifecycle Framework
Stage 0: Conceptualization Initiation
Concept
Planning
Stage 1: Requirements Requirements Analysis
Engineering
Stage 2: System Design Design
Stage 3: System Development Development
Stage 4: System Testing Test
Stage 5: System Deployment & Implementation
Operation Operations and Maintenance
Disposition

Waterfall Software Development Model
Royce, W. (1970). Managing The Development of Large

Software Systems. IEEE WESCON.

Waterfall: Documentation

IEEE WESCON.
Waterfall: Preliminary Program Design

IEEE WESCON.
Waterfall: Plan, Control, Testing

IEEE WESCON.
Waterfall: Critical Software Review

IEEE WESCON.
After the Class
• Review Concept of Operations for a software project
later this week.
• Review the Project Slides.
– Create Group
– Select Option
• Begin to think about the types of requirements that you
will have to define:
– Based on what we talked about briefly here and what you read in
Sommerville.


CS6231 SWEngineering Lecture 1b SE Introduction

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CS6231 SWEngineering Lecture 1b SE Introduction

Uploaded by

Copyright:

Available Formats

CSCI-6231: Software Engineering

The life-cycle model. Requirements and

• An information system (IS) can be defined technically as a set of

09/16/2023 CSCI 6231 - Software Engineering 1-3

09/16/2023 CSCI 6231 - Software Engineering 1-4

Development Using Support

09/16/2023 CSCI 6231 - Software Engineering 1-5

Development Using Support

09/16/2023 CSCI 6231 - Software Engineering 1-6

09/16/2023 CSCI 6231 - Software Engineering 1-7

09/16/2023 CSCI 6231 - Software Engineering 1-8

09/16/2023 CSCI 6231 - Software Engineering 1-9

09/16/2023 CSCI 6231 - Software Engineering 1-10

09/16/2023 CSCI 6231 - Software Engineering 1-11

09/16/2023 CSCI 6231 - Software Engineering 1-12

• How do you use the information system?

• Who else uses the system?

• How do others use the data?

09/16/2023 CSCI 6231 - Software Engineering 1-13

• Does the system provide data to other systems?

• Does the data from the system support other processes?

09/16/2023 CSCI 6231 - Software Engineering 1-14

• How do you use the site?

• What features do you use from the site?

• What do you like about the site? Dislike?

09/16/2023 CSCI 6231 - Software Engineering 1-15

• After you place your order what happens?

– What other processes does the system need to support?

09/16/2023 CSCI 6231 - Software Engineering 1-16

• Software Engineering is about designing and developing high-quality

• Software engineering is the application of a systematic, disciplined,

09/16/2023 CSCI 6231 - Software Engineering 17

09/16/2023 CSCI 6231 - Software Engineering 1-18

09/16/2023 CSCI 6231 - Software Engineering 1-20

09/16/2023 CSCI 6231 - Software Engineering 1-21

• For problem solving, we use

09/16/2023 CSCI 6231 - Software Engineering 1-23

1960s 1970s 1980s 1990s 2000s

09/16/2023 CSCI 6231 - Software Engineering 1-24

09/16/2023 CSCI 6231 - Software Engineering 1-25

09/16/2023 CSCI 6231 - Software Engineering 1-26

09/16/2023 CSCI 6231 - Software Engineering 1-27

09/16/2023 CSCI 6231 - Software Engineering 1-28

09/16/2023 CSCI 6231 - Software Engineering 1-29

First law of software engineering

Source: Ivan Marsic, Rutgers University

Source: Ivan Marsic, Rutgers University

May be the Programmer’s task:

09/16/2023 CSCI 6231 - Software Engineering 1-31

09/16/2023 CSCI 6231 - Software Engineering 1-32

Implementation The Granddaddy of

09/16/2023 CSCI 6231 - Software Engineering 1-33

Royce, W. (1970). Managing The Development of Large

09/16/2023 CS 6231 - Software Engineering 8b-34

Royce, W. (1970). Managing The

Royce, W. (1970). Managing The

Royce, W. (1970). Managing The

Royce, W. (1970). Managing The

09/16/2023 CSCI 6231 - Software Engineering 1-39

09/16/2023 CSCI 6231 - Software Engineering 1-40

09/16/2023 CSCI 6231 - Software Engineering 1-41

09/16/2023 CSCI 6231 - Software Engineering 1-42

09/16/2023 CSCI 6231 - Software Engineering 1-43