Software Engineering & Project Managment

Module 1 & 2
Evolving role of software
• Software is a product
Delivers Computing Potential
Produces , Manages ,Acquires,Modifies ,Displays or Transmits informations.

• Software is a vehicle for delivering a product.

Supports or directly provides system functionality
Controls other Programs
Effects Communications
Helps build Other Software
Changing nature of Software
• Today, S/w takes dual role. It is a product , at the same time the
vehicle for delivering the product.

• The role of S/w has undergone significant changes.

• Dramatic improvement in h/w performance,vast increase in

memory .storage capacity & wide variety of input & output options.
1.1Defining Software
• Software is :-
An instruction that when executed provide desired
features,function,performance.

Data structures that enable the programs to adequately manipulate

information.
1.2 Software doesn’t wear out
Fig – Failure Curve for Hardware
• The figure shows the failure rate as a function of time for h/w.
• It is often called as Bath tube curve.
• It indicate that h/w exhibits high failure rates at early in its life.
• The failure rate rises as h/w component suffer from cumulative effects
of dust,vibration,temperature extremes.
Fig :- Failure Cure for Software
1.3 S/W Application Domains
1. System Software
2. Application Software
3. Embedded Software
4. Web Application
5. Net Sourcing
6. Open Source ………
1.4 Legacy Software
• The older programs are often reffered as Legacy Software.

• Legacy software systems were developed decades ago and have been
continually modified to meet changes in business requirments and
computing platform
Software Engineering
• The application of systematic , disciplined,quantified approach to the
development , operation and maintaince of s/w.
• The S/w includes a layers having
• A quality Focus
• Process
• Methods
• Tools
Process Framework
Process Flow
Process Pattern
• It describes a process – related problem that is encountered during
S/w Engineering work.
• Identifies the environment in which the problem has been
encountered.
• Suggest one or more proven solution to problem.
• Pattern includes –
Pattern Name , Focus , Type ( Stage,Task,Phase ) ,Problem , Solution ,
Resulting Context …….
Process Assesment and
Improvement
• The existence of software process is no guarantee that s/w will be
delivered on time , that will meet customer’s need.
• A number of different approaches to software process assessment &
improvement have been proposed over the past few decades.
• 1)SCAMPI-Standard Assesment method for process improvement.
• 2) CMM Based Appraisal for Internal Process.[Capability Maturity
Model]
• 3)SPICE(ISO/IEC 15504).
• 4)ISO 9001:2000 for software.
Personal and Team Process Models
• To create a personal software/ or a team software process, both
requires hardwork training and co-ordination.
* Personal Software Process ( PSP)-includes 5 framework activities
• 1)Planning
• 2)High- Level Design
• 3)Development
• 4)Postmortem
*Team Software Process (TSP)

1)Goal of TSP is to build a self directed project team that organize itself to produce high quality
software.

2)Build Self-directed teams that plan and track their work , establish goals and own their process
and plan.

3)Show managers how to coach and motivate their teams and help them sustain peak performance.

4)Facilitate university teaching of industry grade team skills.

Process Technology
• Process technology allows a software organization to build an
automated model of the process framework,task sets and umbrella
activities.

• The process technology tool can also used to co-ordinate the use of
the other s/w engineering tools that are appropriate for particular
work task.
Perscpriptive Process Models
• Waterfall Model
• V- Model
• Incremental Process Model
• Evolutionary Process Model- 2 types
• Prototyping
• Spiral Model
Waterfall Model
V Model
Incremental Process Model
Prototyping
Spiral Model
Developing Use case
• Use case tells us the story about how an end – user interact with
system under certain condition.
• First step in writing use case is to define as “Actor”.
• Actors & end –user are not necessarily the same thing.
• It is possible to identify the primary & secondary actor.
• primary actor interacts & achieve req. system function & derive
benefits from system.
• secondary actor supports the system so that primary actor can do
there work
Building the Requirements Model
1) Elements of requirement model
a.Scenario based elements
b.Class based elements
c.Behavioral elements
d.Flow –oriented elements

2)Analysis Pattern
Negotiating Requirements
• Identification of system or sub system key stakeholders.

• Determination of the stakeholders

• Negotiation of the stakeholders, for “Win- Win” result condition for all
concerned ( including Software Team ).
Requirment Analysis
• It allows you to elaborate basic requirement established during the
inception,elicitation,negotiation tasks that are part of Requirment
Engineering.
• Following are types of Models
1)scenario based model of requirement from point of view from
various actors
2)Data Models that describes the information from problem.
3)Class Oriented Models that represent object oriented classes to
achieve system requirment
4)Flow oriented models that represent how the data transforms and
move through the system.
5)Behavioral Model that describes the software behavior as a
consequence of external events.

Finally , the requirements model provides developer & customer with

the means to asses once software is built.
1.1 Overall Objectives and
Philosophy
• Describe what customer requires.

• Establish the basis for the creation of software design.

• Define the requirement that can be validated once software is built.

• The analysis model bridges the gap between software - level description that
describes overall system functionality.

• By achieving the proper software design that describes application architecture and
component-level structure.
The Bridge
1.2 Analysis Rule of Thumb
• The model should focus on requirements that are visible within the problem or
business domain. The level of abstraction should be relatively high.
• Each element of the analysis model should add to an overall understanding of
software requirements and provide insight into the information domain, function
and behavior of the system.
• Delay consideration of infrastructure and other nonfunctional models until
design.
• Minimize coupling throughout the system.
• Be certain that the analysis model provides value to all stakeholders.
• Keep the model as simple as it can be.
1.3 Domain Analysis
• Software Domain analysis is identification,analysis , specification of
common requirments from a specification domain, typically for reuse
on multiple projects with in that application domain.
Input and Output for domain
analysis
Domain Analysis
• Define the domain to be investigated.
• Collect a representative sample of applications in the domain.
• Analyze each application in the sample.
• Develop an analysis model for the objects.
Requirment Modeling Approaches
Scenario – Based Modeling
• The success of Computer –based System is measured in many ways,
user satisfaction resides at the top of the list.
• The creation of use-case ,activity diagram,swimlane diagram are done
by means of UML.
1)Creating a Preliminary Use-Case
• Use-Case capture the interaction between producers & Consumers
• Eg- Safe Home Surveillance Function of Camera via -Internet
Preliminary Use-case diagram for
Safe Home
2)Refining Preliminary Use-Case
• The step of prelimnary use-cases listed are evaluated by asking
certain question.
Writing Formal Use-Case
• As described in previous steps , its an informal use-case presented are
sometime sufficient for requirement modeling.
• However, when a use-case involves criticalvactivities , then formal
approaches is desirable.
• Use-case focus on behavior & functional requirement.
• Scenario-Based Modeling is appropriate for all situation that
encounter as software engineer.
UML Models that supplement the
use-cases
1)Developing Activity Diagram

*It provides graphical representation of flow of interaction with specific

scenarios.
*An Activity diagram for ACS-DCV is describes the activity of
survelliance function of camera.

* For example , a use may attempt to enter USERID & PASSWORD a

limited number of times.
2)Swimlane Diagram

• The Swimlane Diagram illustrate the activity,is re-arranged so that

associated with particular analysis.

• “Interface” class represent the user interface as seen by the home

owner.
Class-Based Modeling
• The elements in class base model includes the classes and objects,
attributes ,operations, class-responsibility-collaborator models.

1.Identifying Analysis Classes

We begin to identify the classes by examing the usage scenarios
developed as part of requirement model and performance.
Analysis classes manifest themselves in one of the following ways

• External Entities –Eg:- system,devices,people that produce or consume

information to be used by computer-base system.

• Things-Eg:-Reports,displays,letters that are patrt of information domain

for the problem

• Roles – Eg:- (Managers, engineer, salesperson)played by people who

interact with the system
Safe Home Security Function
• The security function enables the home-owner to configure the
security system when it is installed.
 2.Specifying attributes
• Attributes describe a class that has been selected for inclusion in the
requirement model.
• Lets consider
3.Defining Operations
• Operations defines the behaviour of objects.
• They are generally defined into 4 categories
1) Operations that manipulate data –add,delete,select,Re-format
2) Operation that perofrm computation.
3) Operation that inquires about the state of object.
4) Operation that monitor an object for the occurance of a controlling
events.
• The above categories indicates the number of things

assign( ) operation is relevant for sensor class.

program( ) operation is applied for system class.

arm() or disarm() operation is applied for system class.