1

Instructor: S. Masoud Sadjadi

http://www.cs.fiu.edu/~sadjadi/Teaching/sadjadi At cs Dot fiu Dot edu

Software Engineering Software Engineering and and

Project CommunicationsProject Communications

2

AgendaAgenda

Overview of Software Engineering

Software Processes

Software Life Cycle

Project Communications

3

Our IntentionOur Intention

Requirements

Software

4

Our plan of attackOur plan of attack

RequirementsAnalysis

Design

Implementation

Testing

Delivery and Installation

5

AgendaAgenda

Overview of Software Engineering

Software Processes

Software Life Cycle

Project Communications

6

Software ProcessesSoftware 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).

7

Software Specification Software Specification (1)(1)

Functionality of the software and constraints (non-functional 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).

8

Software Specification Software Specification (2)(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.

9

Software Development Software Development (1)(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.

10

Software Development Software Development (2)(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.

11

Software Development Software Development ActivitiesActivities

ProblemDomain

ImplementationDomain

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?

12

Software Validation Software Validation (1)(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.

13

Software Validation (2)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.

14

Software EvolutionSoftware 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.

15

AgendaAgenda

Overview of Software Engineering

Software Processes

Software Life Cycle

Project Communications

16

Software Life CycleSoftware 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.

17

Software Life CycleSoftware Life Cycle

Software construction goes through a progression of states

DevelopmentDevelopment Post- Development

Pre- Development

Conception ChildhoodChildhood Adulthood Retirement

18

Software Life Cycle ModelsSoftware 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

19

Waterfall Model Waterfall Model (1)(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

20

Waterfall Model Waterfall Model (2)(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.

21

Spiral Model Spiral Model (1)(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.

22

Spiral Model Spiral Model (2)(2)

Requirementsplan

Concept ofoperation

Riskanalysis

Prototype1

Prototype2

Prototype3

Riskanalysis

Riskanalysis

S/wReqs.

Reqs.Validation

DevelopmentPlan

IntegrationPlan

DesignValidation

AcceptanceTest

Sys.ProductDesign

Integration &Test

Unit Test

Code

DetailedDesign

Design objectives,alternatives, and constraints

Plan next phase

Evaluate alternatives,identify and resolve risks

Develop and verifynext level product

Not shown in detail

23

Spiral Model Spiral Model (3)(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

24

Incremental Development Incremental Development (1)(1)

Mills et al. 1980

Define outlinerequirements

Assign requirementsto increments

Design systemarchitecture

Develop systemincrement

Validateincrement

Integrateincrement

Validatesystem

System incomplete

Finalsystem

25

Incremental Development Incremental Development (2)(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.

26

Incremental Development Incremental Development (3)(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.

27

Extreme ProgrammingExtreme 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!

28

AgendaAgenda

Overview of Software Engineering

Software Processes

Software Life Cycle

Project Communications

29

Communication EventCommunication 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

30

Communication mechanismCommunication 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.

31

Classification of Classification of CommunicationCommunication

Synchronous– Hallway conversation

– Meeting in person

– Online meetings EVO, Skype, Chat, etc.

– Phone conversation

Asynchronous– E-Mail

– Instant messaging

– Group Forums

– Wiki pages

is supported by

* *

SynchronousMechanism

AsynchronousMechanism

CommunicationMechanism

UnplannedEvent

PlannedEvent

CommunicationEvent

32

Planned Communication Planned Communication Events Events 22

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.

33

Planned Communication Planned Communication Events Events 33

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.

34

Planned Communication Planned Communication Events Events 44

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.

35

Unplanned Communication Unplanned Communication EventsEvents

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

36

SummarySummary

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.