Transcript Lecture 2: Software Engineering and Project Communications

Software Engineering
and
Project Communications
Instructor: S. Masoud Sadjadi
http://www.cs.fiu.edu/~sadjadi/Teaching/
sadjadi At cs Dot fiu Dot edu
1
Agenda

Overview of Software Engineering

Software Processes

Software Life Cycle

Project Communications
2
Our Intention
Requirements
Software
3
Our plan of attack
Requirements
Analysis
Design
Implementation
Testing
Delivery and Installation
4
Agenda

Overview of Software Engineering

Software Processes

Software Life Cycle

Project Communications
5
Software Processes

Specification
– requirements elicitation and analysis.

Development
– systems design, detailed design (OO design), implementation.

Validation
– validating system against requirements (testing).

Evolution
– meet changing customer needs and error correction
(maintenance).
6
Software Specification (1)



Functionality of the software and constraints (nonfunctional requirements) on its operation must be defined.
functional requirement – describes the interaction
between the system and its actors (e.g., end users and
other external systems) independent of its implementation.
nonfunctional requirement – describes aspects of the
system that are not directly related to the functional
requirements of the system (e.g., QoS, security,
scalability, performance, and fault-tolerance).
7
Software Specification (2)

Involves:
– Requirements elicitation
– The client and developers define the purpose of the system.
– Output is a description of the system in terms of actors and uses
cases.
– Actors include roles such as end users and other computers the
system needs.

Uses cases are general sequences of events that describe all
possible actions between actor and the system for a given piece of
functionality.
Analysis

Objective: produce a model of the system that is correct, complete,
consistent, unambiguous, realistic, and verifiable.
8
Software Development (1)

Producing the software that meets the
specification.
System Design



Goals of the project are defined.
System decomposed into smaller subsystems (architectural model).
Strategies to build system identified
– HW and SW platform, data management, control flow, and security.

Output: model describing subsystem decomposition and system
strategies.
9
Software Development (2)
Object Design

Bridges the gap between analysis model and the strategies identified in the
system design.
Includes:
– Describing object and subsystem interfaces
– Selecting off–the-shelf components
– Restructure object model to attain design goals


e.g., extensibility, understandability, and required performance.
Output: detailed object model annotated with constraints and supporting
documentation.
Implementation



Translation of the object model into source code.
No general process followed.
There are tools to assists the programmer such as CASE tools.
10
Software Development Activities
Requirements Analysis
What is the problem?
System Design
What is the solution?
Object Design
What is the solution in
a specific context?
Implementation
How is the solution
constructed?
Problem
Domain
Implementation
Domain
11
Software Validation (1)


Ensures the software does what the customer want.
The software conforms to its specification and meets the
expectations of the customer.
Validation: ‘Are we building the right product?’
Ensures the software meets the expectations of the customer.
Verification: ‘Are we building the product right?’
Ensures the software conforms to the specification.
12
Software Validation (2)

Techniques
– Software inspections (static):

Analyze and check system representations (e.g., requirements
documents, design diagrams, and program source code).
– Software testing (dynamic):

Executing an implementation of the software with test data and
examining the outputs against expected results.

V&V process establishes the existence of defects.

Debugging is a process that locates and corrects these
defects.
13
Software Evolution

Software must evolve to meet the customer
needs.

Software maintenance is the process of changing a
system after it has been delivered.

Reasons for maintenance
– To repair faults.
– To adapt the software to a different operating environment.
– To add to or modify system’s functionality.
14
Agenda

Overview of Software Engineering

Software Processes

Software Life Cycle

Project Communications
15
Software Life Cycle

Software life cycle modeling
– Attempt to deal with complexity and change.

Software life cycle
– Set of activities and their relationships to each other to support the
development of a software system .

Software development methodology
– A collection of techniques for building models, which are applied
across the software lifecycle.
16
Software Life Cycle

Software construction goes through a progression of
states
Conception
PreDevelopment
Childhood
Development
Adulthood
Retirement
PostDevelopment
17
Software Life Cycle Models

Waterfall model and its problems
– Pure Waterfall Model
– V-Model

Iterative process models
– Boehm’s Spiral Model
– Unified Process Model

Entity-based models
– Issue-based Development Model
– Concurrent Development
18
Waterfall Model (1)

The waterfall model
– First described by Royce in 1970

There seem to be at least as many versions as there are
authorities - perhaps more
Requirements
Definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance
19
Waterfall Model (2)

One or more documents are produced after each phase
and “signed off”.

Points to note:
– “Water does not flow up”.

it is difficult to change artifact produced in the previous phase.
– This model should be used only when the requirements are well
understood.
– Reflects engineering practice.
– Simple management model.
20
Spiral Model (1)

Basic Idea
– develop initial implementation, expose it to user, and refine it until
an adequate system is produced.

Two types:
– Exploratory
– Throw-away prototyping

Advantages
– model used when problem is not clearly defined.

Disadvantages
– Process not visible, systems are poorly constructed, may require
special tools and techniques.
21
Spiral Model (2)
Design objectives,
alternatives, and constraints
Evaluate alternatives,
identify and resolve risks
Risk
analysis
Risk
analysis
Risk
analysis
Prototype
3
Prototype
Prototype
2
1
Requirements Concept of
plan operation S/w
Reqs.
Development
Plan
Integration
Plan
Design
Validation
Acceptance
Test
Plan next phase
Detailed
Design
Sys.
Product
Design
Reqs.
Validation
Not shown
in detail
Code
Unit Test
Integration &
Test
Develop and verify
next level product
22
Spiral Model (3)

Tries to accommodate infrequent change during
development.

Each round of the spiral involves:
–
–
–
–
–
–
–
Determine objectives
Specify constraints
Generate alternatives
Identify risks
Resolve risks
Develop and verify next level product
Plan
23
Incremental Development (1)

Mills et al. 1980
Define outline
requirements
Develop system
increment
Assign requirements
to increments
Validate
increment
Integrate
increment
Design system
architecture
Validate
system
Final
system
System incomplete
24
Incremental Development (2)

Software specification, design and implementation is
broken down into a series of increments which are
developed in turn.

Gives customers some opportunities to delay decisions on
the detailed requirements of the system.

Services are identified and a priority allocated.

Each increment provides a subset of the system’s
functionality.
25
Incremental Development (3)
Advantages:
–
–
–
–
Customers do not have to wait for the entire system.
Customers gain experience using early increments of the system.
Lowers the risk of overall project failure.
Most important system services receives the most testing.
Disadvantages:
– May be difficult to map meaningful functionality into small
increments.
26
Extreme Programming

The incremental approach has evolved to ‘extreme
programming’ (Beck 1988).

Extreme programming:
–
–
–
–
Development and delivery of very small increments.
Customer involvement in the process.
Constant code improvement.
Egoless programming

Programs are regarded as group property!
27
Agenda

Overview of Software Engineering

Software Processes

Software Life Cycle

Project Communications
28
Communication Event
Type of information exchange that has defined objectives
and scope

Scheduled
– Planned communication
– For example, review, meeting

Unscheduled
– Event-driven communication
– For example, request for change, issue clarification, problem report
29
Communication mechanism
Tool or procedure that can be used to transmit information

Synchronous
– Sender and receiver are available at the same time.

Asynchronous
– Sender and Receiver are not communicating at the same time.
30
Classification of Communication
Communication
Event
Planned
Event

*
Unplanned
Event
Synchronous
– Hallway conversation
– Meeting in person
– Online meetings

is supported by
EVO, Skype, Chat, etc.
Communication
Mechanism
*
Synchronous
Mechanism

Asynchronous
Mechanism
Asynchronous
–
–
–
–
E-Mail
Instant messaging
Group Forums
Wiki pages
– Phone conversation
31
Planned Communication Events 2

Walkthrough (Informal)
– Objective: Increase quality of subsystem.
– Example: Developer presents subsystem to team members,
informal, peer-to-peer.
– To be scheduled by each team.

Inspection (Formal)
– Objective: Compliance with requirements.
– Example: Client acceptance test (Demonstration of final system to
customer).
– To be scheduled by project management.
32
Planned Communication Events 3

Status Review
– Objective: Find deviations from schedule and correct them or
identify new issues.
– Example: Status section in regular weekly team meeting.
– Scheduled every week.

Brainstorming
– Objective: Generate and evaluate large number of solutions for a
problem.
– Example: Discussion section in regular weekly team meeting .
– Scheduled every week.
33
Planned Communication Events 4

Release
– Objective: Baseline the result of each software development
activity.
– Software Project Management Plan (SPMP)
– Requirements Analysis Document (RAD)
– System Design Document (SDD)
– Object Design Document (ODD)
– Test Manual (TM)
– User Manual (UM)
– Usually scheduled after each phase

Postmortem Review
– Objective: Describe Lessons Learned.
– Scheduled at the end of the project.
34
Unplanned Communication Events

Request for clarification
– The bulk of communication among developers, clients and users.
– Example: A developer may request a clarification about an ambiguous
sentence in the problem statement.

Request for change
– A participant reports a problem and proposes a solution
– Change requests are often formalized when the project size is substantial.
– Example: A participant reports of a problem the air conditioner in the
lecture room and suggests a change.

Issue resolution
– Selects a single solution to a problem for which several solutions have
been proposed.
– Uses issue base to collect problems and proposals
35
Summary

Communication Events
– Planned
– Unplanned

Communication Mechanisms
– Asynchronous
– Synchronous

Important events and mechanisms
– Sync. Communications

Class meetings, weekly group meetings, project reviews, chat, etc.
– Async. communication

Group forums, email, wiki pages, instant messaging, etc.
36