Intro to software Engineer

Rapid Prototyping (Process)

Work in manageable modules Build it rapidly Modify the prototype in successive iterations Stress the user interface

Pro-type Model

a protype is a partial implementation of the final product

Quality Planning

Decide the procedures to a specific project.

Each architectural style supports some quality features.

...

Software Sizing

Lines of Code (LOC) Function Points (FP)

repeatable

Focuses on basic project management

Slack Time

Slack Time = (LS - ES)

General Model

Effort = [a + (b * ((Size)**c))] * [PROD(f's)]

optimizing.

Focuses on continuous process improvement

Iterative Development Process Model

It combines pro-typing with the waterfall

Quality Assurance Managers

Quality assurance, planning , and control

Software Design Specification

From the SDD, the system is then implemented using programming language/s, which is followed by debugging, testing, and maintenance.

Expected task time (e-t-t)

(optimistic-time + 4*most-likely-time + pessimistic-time)/6

As the description of software construction structure, an architectural design must cover the software functional requirements and non-functional requirements as well.

...

Each style represents a layout topology of elements, and connections and interactions among these.

...

It shows how the system is structured in terms of components, and how its components work together.

...

Quality attributes are closely related to architectural styles.

...

The architectural design embodies earliest decisions that have a decisive impact on the ultimate success of the software product.

...

TSP objectives (as defined by Humphry:)

1. Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. 2. Show managers how to coach and motivate their teams and how to help them sustain peak performance. 3. Accelerate software process improvement by making CMM Level-5 behavior normal and expected. 4. Provide improvement guidance to high-maturity organizations. 5. Facilitate university teaching of industrial-grade team skills.

Software architect's tasks

1.Perform system static partitioning and decomposition into sub-systems and communications between sub-systems. 2.Establish dynamic control relationships between different sub-systems in terms of data flow, or control flow orchestration, or message dispatching. 3.Consider and evaluate alternative architecture styles for the problem at hand. 4.Perform trade-off analysis on quality attributes and other non-functional requirements during the selection of architecture styles. 5.Map the software requirements specification to the software architecture and guarantee that the software architecture satisfies functional and non-functional requirements (very important task).

General Description

2. General Description Product Perspective Product Functions User Characteristics General Constraints Assumptions

Specific Requirements

3. Specific Requirements 3.1 Functional Requirements 3.1.1Functional Requirements 1 Specification Introduction Inputs Processing Outputs External Interfaces User Interfaces Hardware Interfaces Software Interfaces Communication Interfaces 3.1.2Functional Requirements 2 . . 3.1.n Functional Requirements n 3.2 Performance Requirements 3.3 Design Constrains 3.4 Attributes 3.4.1 Security 3.4.2 Maintainability . . . 3.5 Other Requirements Database Operations Site Adaption

Software process

A framework of task needed to complete a high quality software.

FUNCTIONAL REQUIREMENTS

A functional requirement describes an interaction between the system and its environment, and how the system should behave under certain circumstances. For example consider Self-Registration system Allow eligible students to register for courses

MODULES

A module is a system component that provides one or more services to other modules.

NONFUNCTIONAL REQUIREMENTS

A nonfunctional requirement (or constraint) describes a restriction on the system.

What is a Requirement?

A requirement is a feature of the system or a description of something the system is capable of doing in order to fulfill the system's purpose.

SUB-SYSTEMS

A system in its own right whose operation does not depend on the services provided by other sub-systems.

Rapid Prototyping

A working model that is functionally equivalent to a subset of the product.

Process of training

All personal must be trained in order to the job.

Activities/Tasks

An activity/task is a part of the project that takes place over a period of time.

SUB-SYSTEMS

Are composed of modules and have defined interfaces which are used for communication with other sub-systems.

Maintenance

Are enhancements needed? After the product is delivered, we need to follow up and find out if any improvements or enhancements are needed.

Delivery

Can the customer use the solution? Here we have to make sure that the customer can use the product. We may need to help with training, product installation, etc.

Inital

Chaotic-unpredictable cost, schedule, and quality performance.

The PSP process

Consists of a set of methods, forms, and scripts that show software engineers how to plan, measure, and manage their work.

SRS - IEEE Standard

Consists of three sections Introduction General Description Specific Requirements

Requirements Priorities

Current user/customer demands or needs Competition and current market condition Anticipated future and new customer needs Sales advantages Critical problems in existing product

Software Design

Design is the creative process of transforming the problem into a solution.

Parameters of Activities

Duration Number of days that it takes to complete the activity Milestone Completion of an activity Predecessor An event (or a set of events) that must occur before the activity can begin Due date The date by which the activity must be completed

Architectural Design

During the architectural design step we describe user accessible components and the interconnections among them that are visible to stakeholders.

Detailed Design

During the detailed design step we specify the internal details of each component and we might introduce new invisible components - to the stakeholder, into the design.

Function Point (FP) = Initial FP x TCF

Effort = A * B * (size ** C)

Quality Assurance

Establishes the procedures standards that lead to high quality software.

defined

Focuses on process standardization.

managed,

Focuses on quantitative management.

Software Design

Here (software design phase) we concentrate on HOW to do it.

Design

How is the software going to be structured? What are the components (Modules) How are these components related

Program Implementation

How is the solution constructed? Here we do the actual coding. Algorithms, charts, etc. are converted to programs.

The PSP shows engineers

How to manage quality from the beginning of the job, How to analyze the results of each job, and How to use the results to improve the process for the next project

View Oriented Requirements Definition (VORD) is based on the concept that requirements are viewed differently by different people

Identify stakeholders and their viewpoints of the requirements Categorize the viewpoints of requirements and eliminate any duplication Refine the identified viewpoints of requirements Map the viewpoints of requirements to the system and the services that the system must provide

Capability mature model

Initial, repeatable, defined, managed, optimizing.

Information Collection

Interview Questionnaire

Introduction

Introduction Purpose Scope Definition, Acronyms, or Abbreviations References Overview

Testing

Is the problem solved? Here we make sure that every program is working, and they also work together correctly and produce correct results (as expected from the product.)

Process Model

It is a description of what tasks need to be done in what sequence under what conditions by whom to achieve the "desired results."

spiral model

It is based on experience of various refinements of the waterfall model. applied to large governmental systems.

MODULES

It makes use of services provided by other modules. It is not normally considered to be an independent system.

Process monitoring and enforcement

Make sure all personal is following the process.

Quality control

Make sure the procedures are being followed by the developing team.

Requirements Prioritization

Most of the time we have limitations of : Time Resources Technical capabilities

Requirements Definition/Prototyping/Review

Once the requirements are solicited, analyzed and prioritized, more details must be spelled out. Three major activities which may be intertwined must be performed: Requirements definition Requirements prototyping Requirements reviewing

COCOMO I

Organic : less complex and flexible process Semidetached : average project Embedded : complex, real-time defense projects

Quality Attributes

Performance Reliability Portability Usability Security Testability Modifiability Etc.

Process Models

Personal Software Process (PSP) Team Software Process (TSP)

Aspects of process

Process of definition, Process of training, Process monitoring and enforcement.

Why have a process Model?

Provides coordination and control of task and personnel.

Information Sought

Reactions Suggestions Innovations Revision plans

SDLC (Software Development Life-Cycle) Waterfall Model

Requirements Analysis System design Program Design Program Implementation Testing Delivery Maintenance

Requirements Analysis

Requirements analysis is composed of: Categorizing the requirements Prioritizing the requirements

Characteristics of "good" requirements

Requirements must be CORRECT=They should conform to our understanding of the problem. Requirements must be COMPLETE=All scenarios must be considered or requirements are not complete. Requirements must be CONSISTENT=Requirements should not conflict. Requirements must be REALISTIC=Can they really be done? Requirements must be VERIFIABLE=Once project done, we should be able to prove that they are satisfied. Requirements must be NEEDED=Are they really needed (the customer's needs?) Requirements must be TRACEABLE=Are they organized for easy reference?

Requirements Comparison and Prioritization

Requirements prioritization is an activity of comparing the requirements and placing them in some order relative to each other.

Software Quality attributes

Security, safety, complexity, efficiency

Requirements definitions may be written in different forms:

Simple Input/process/output descriptions in English Dataflow diagrams (DFD) Entity Relations diagrams (ERD) Use Case Diagram from Unified Modeling Language (UML)

Software Design

Software Product Design Software Engineering Design

SOFTWARE ARCHITECTURE

Software architects use various design strategies in software construction to divide and conquer the complexities of a problem domain and solve the problem.

What do software engineer do?

Software engineers use tools, techniques, procedures, and paradigms to enhance the quality of software.

Synthesis

Takes smaller problems and combine them to solve a big problem.

analysis

Takes the problem and separate into smaller problems.

Software Design Specification

The SDD describes the components of a system, the modules that comprise each component, and the detailed information (such as data, attributes, operations, and algorithms) of each module.

Software Design Specification

The SDS (SDD) describes the software architecture or high-level design and the detailed design of the system.

Software Requirements Specification

The SRS is the result of requirement analysis; it records the functional and non-functional requirements that must be met by the software system.

Software Architecture: Bridging Requirements and Implementation

The actual design is a blueprint and a guideline for developing a software system based on the software requirement analysis specification.

Team Software Process (TSP)

The goal is to create a "self directed" project development team well organized for the development of high quality software.

The PSP Principle

The principle behind the PSP is that to produce quality software systems. (every engineer who works on the system must do quality work)

The mode of the project is chosen based on 8 parameters

The team's understanding of the project objectives The team's experience with related projects. The project needs to conform with requirements. The project needs to conform with external interfaces. The need to develop the project concurrently with new systems/new operational procedures. The project's need for new technology, architecture, etc. The project's need to meet the schedule. Project size

Planning and Managing the Project

Two major components: Estimating Completion/duration of the project Estimating the cost

Process of developing

Understand the problem,perform some design, code/implement, validate/test the program.

Requirements prototyping mostly address the User Interface (UI) part of the requirement in terms of:

Visual looks (size, shape, position, color) Flow (control and logical flow)

Program Design

What are the mechanisms that best implement the solution? We already know what the problem is, and we also have a good solution. Here we have to figure out mechanisms (e.g., algorithms) that best implement the solution.

Requirements Analysis

What is the problem? Here we have to carefully define the problem. We need to know what must be done, rather than how to do it.

System design

What is the solution? Here we have to find a "good" solution to the problem.

Information Sought

When you show (run) your model watch for reactions (of customer, users, etc.) Are they Happy? Satisfied? Shocked? Surprised? ?

Waterfall Model

encourages the development team to specify what needs to be done first

Function Point (FP)

input items (external input items from user or another application) output items (external outputs such as reports, messages, screens - not each data item) Queries (a query that results in a response of one or more data) master and logical files (internal file or data structure or data table) external interfaces (data or sets of data sent to external devices, applications, etc.)

Software engineering design

is the activity of specifying programs and sub-systems, and their constituent parts and workings, to meet software product specifications.

Software product design

is the activity of specifying software product features, capabilities, and interfaces to satisfy client needs and desires.

software architecture specification

must describe not only the elements and connections between elements but also the constraints and runtime behaviors so that developers know what must be implemented and how it should be implemented.

Process of definition

process must be carefully defined

A good software design

reduces risks in software production, coordinates development teams to work together orderly, makes the system traceable for implementation and testing, and leads to software products that have higher quality attributes.