Design of Secure Multi-Tier Web-Based Database Applications

1
Software Engineering and Project Communications
Instructor S. Masoud Sadjadi http//www.cs.fiu.ed
u/sadjadi/Teaching/ sadjadi At cs Dot fiu Dot
edu
2
Agenda

• Overview of Software Engineering
• Software Processes
• Software Life Cycle
• Project Communications

3
Our Intention
Requirements
Software
4
Our plan of attack
5
Agenda

• Overview of Software Engineering
• Software Processes
• Software Life Cycle
• Project Communications

6
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).

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

• Object Design
• Bridges the gap between analysis model and the
  strategies identified in the system design.
• Includes
• Describing object and subsystem interfaces
• Selecting offthe-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 Activities
What is the problem?
What is the solution?
Problem Domain
Implementation Domain
What is the solution in a specific context?
How is the solution constructed?
12
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.

13
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.
• VV process establishes the existence of defects.
• Debugging is a process that locates and corrects
  these defects.

14
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 systems functionality.

15
Agenda

• Overview of Software Engineering
• Software Processes
• Software Life Cycle
• Project Communications

16
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.

17
Software Life Cycle

• Software construction goes through a progression
  of states

Adulthood
Retirement
Childhood
Conception
Post- Development
Pre- Development
Development
18
Software Life Cycle Models

• Waterfall model and its problems
• Pure Waterfall Model
• V-Model
• Iterative process models
• Boehms Spiral Model
• Unified Process Model
• Entity-based models
• Issue-based Development Model
• Concurrent Development

19
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

20
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.

21
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.

22
Spiral Model (2)
Design objectives, alternatives, and constraints
Evaluate alternatives, identify and resolve risks
Risk analysis
Risk analysis
Risk analysis
Prototype 3
Not shown in detail
Prototype 2
Prototype 1
Concept of operation
Requirements plan
S/w Reqs.
Detailed Design
Sys. Product Design
Development Plan
Reqs. Validation
Code
Integration Plan
Design Validation
Unit Test
Integration Test
Acceptance Test
Develop and verify next level product
Plan next phase
23
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

24
Incremental Development (1)

• Mills et al. 1980

25
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 systems
  functionality.

26
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.

27
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!

28
Agenda

• Overview of Software Engineering
• Software Processes
• Software Life Cycle
• Project Communications

29
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

30
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.

31
Classification of Communication

• Synchronous
• Hallway conversation
• Meeting in person
• Online meetings
• EVO, Skype, Chat, etc.
• Phone conversation

• Asynchronous
• E-Mail
• Instant messaging
• Group Forums
• Wiki pages

32
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.

33
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.

34
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.

35
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

36
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.