Software Lifecycles - Curry

lumpysteerΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

71 εμφανίσεις

Introduction to

Software Engineering

Definition and properties


A system is a collection of interrelated
components that work together to achieve
some objective


Properties :


Complex interrelationship among the
parts


Reliability


Usability

System & its environment


We create a system to modify/adapt to the
environment


There are internal & external relationships
between the system and it’s environment

Procurement


To buy


To design from scratch



Large systems : mix of bought and designed
systems


Others : really start from scratch using a
development tool.

System customer

Principal

contractor

Subcontractor 1

Subcontractor 1

Subcontractor 1

Software Engineering


“The profession concerned with creating and
maintaining software applications by applying
computer science, project management, domain
knowledge and other skills and technologies”


“SE technologies and practices (databases,
libraries, patterns, platforms, processes, etc.) help
developers by improving productivity and quality”

SE


Pressman

“An outgrowth of hardware and systems
engineering. It encompasses a set of three
key elements


methods, tools, and
procedures
--

that enable the manager to
control the process of software development
and provide the practitioner with a
foundation for building high
-
quality
software in a productive manner.”

The classic life cycle


Systems Engineering (requirements
gathering)


Analysis


Design


Code


Testing


Maintenance


The system engineering process


Requirements definition


Systems Design


Sub
-
system development


System Integration


System installation


System evolution


System decommissioning

System requirements definition


Determine


Coarse grain functional requirements
(what are the basic functions of the
system)


System properties (availability,
performance, safety, security)


What it should not exhibit

System design


Partition requirements


Identify sub
-
systems


assign requirements to sub
-
systems


Specify sub
-
system functionality


Define sub
-
system interfaces

Sub
-
system developmemt


Development of the sub
-
systems


Programming

System integration


Putting together independently development
sub
-
systems into one coherent system

System Installation


Problems


Different environment in which the
system is to be installed (OS,
development software version)


Human resistance


Co
-
existence with an old system


Physical installation problems

Final stages


System operation


training, changing the normal work process


System evolution


feedback and changes in the environment


change is costly


System decommissioning


Putting the system out of service

Software Lifecycles

Definition

Software Lifecycle refers to the progression of
the software system from development
through maintenance and eventually
replacement.


Involves the activities in the production of a
software system.

Phases : In General


Requirements analysis and specification


Design


Preliminary Design


Detailed Design


Implementation


Testing


Unit testing


Integration Testing


System Testing


Installation and Acceptance Testing


Maintenance

Examples of Software Lifecycles


Waterfall model


Modified Waterfall Model


Prototyping


Boehm’s Spiral model


Object
-
Oriented Analysis

Waterfall Model


Derived from other engineering processes in the ‘70s


Offered a means of making the development process more
structured


Expresses the interaction between subsequent phases


Each phase cascades into the next


Original WM :


A strict sequence was implied


Did not provide feedback

Modified Waterfall Model


Need to provide for overlap and feedback between phases


It is iterative compared to the linear model of the original
WM


Verification and validation are added


Verification checks that the system is correct


Validation checks that the system meets the users
desires


Comments on WM


Inflexible in the partitioning of the project in
distinct phases


Reflect common engineering practices


Emphasis


Discerning the users needs and requirements
prior to the system being built


Agreement bet. User and developer with
respect to the requirements

Comments on WM


Exclusively document
-
driven models


Some facts


50% of the design effort occurs during the actual
design phase


1/3 of the design effort done in the coding activity


16% of the design effort occurs after the system is
supposed to be completed


People using this type of model are opportunistic.
There is a need for strictness and signoffs in terms of
documentation

Prototyping


Aims to enhance the accuracy of the designers
perception of the user’s requirements


Develop an initial system for user feedback and
then refine by developing a lot of versions until a
satisfactory system emerges


Rapid development is the key

Types


Exploratory


Start with parts which are understood and
then evolves as the user proposed new
features


Throw Away


Focus is more on poorly understood
concepts

Comments


Took 40% less time and 45% less code


Produced code which is not as robust and more
difficult to maintain


Less documentation is present

Boehm’s Spiral Model


An improved model where all generic
models have been considered


Boehm proposed a spiral model where each
round of the spiral


Identifies the subproblem which has the
highest risk associated with it


Finds a solution to that problem

Object Oriented Analysis


Activities


Object
-
oriented analysis


Object
-
oriented design


Object
-
oriented programming


Main difference between the other models :
Modeling of the system components using object
-
oriented concepts and techniques in programming.

Planning and Cost Estimation

Planning


All software development should be planned,
including analysis and assessment


Provides a means for effective management of a
software project
--

identifies problems and possible
solutions


Involves


Delivery date


Available Staff


Budget


Staff Expense

Estimates


Project Structure


Project Size


Functions and their hierarchical
relationships

Project Plan


Indicates available resources, work
breakdown and a schedule for completion


Documentation


Introduction


Describe objectives and constraints


Organization


Team organization, team roles, team members


Risk Analysis


Describe possible risks and solutions


Resource requirements


Hardware and Software

Documentation


Work Breakdown


Composed of activities, milestones, tasks and
deliverables


Milestones : ending point for a SW activity


Milestones are composed of tasks


Deliverables : To be given to the customer


Schedule


Reporting Mechanisms


Management reports required and their due
dates

Project Scheduling


Difficult and dependent on the experience of the
project manager


Initially optimistic


Do not only estimate time, but also resources like
people and equipment

Cost Estimation


Like Project scheduling, is also dependent
on the PM’s experience


A lot of cost estimation techniques and a lot
of companies have their own charts in
estimating cost and what consists of costs

Types of estimation


Algorithmic Cost modeling


Uses historical cost which relates
software size to cost


Expert judgement


Experts estimate how much the proj. will
cost and then it is discussed


Estimation by analogy


Uses other similar projects as basis

Types of estimation


Parkinson’s Law


“Work expands to fill the time available”


Cost is determined by available resources
rather than by objective assessment


12 mo x 5 people = 60 person
-
months


Pricing to Win


Based on the customer’s budget

COCOMO Model


Algorithmic approach


Well documented and one of more widely used
cost
-
estimation models


Based on the model :

Effort = C* PM ^s * M


C is complexity of the project, PM is some product metric
(usually # of lines); M is a multiplier; and s indicates the
increasing effort for large proj. (< 1)

The formula


Basic


Well understood application developed by
small teams.

PM = 2.4(KDSI)^1.05 * M



Moderate


More complex projects whose team members
have limited experience

PM = 3.0(KDSI)^1.12*M

The formula


Embedded


Complex proj. where the software is part of the
a strongly integrated set of HW, SW,
regulations and procedures

PM=3.6(KDSi)^1.20*M

Requirements Analysis &
Specification

Notes


The WHAT phase rather than a HOW phase


WHAT are the user’s needs, WHAT is the current
system, WHAT are the constraints on the current
and future system


Both FUNCTIONAL (describing function or
service) and non
-
functional (time, money, OS
platform)

Document


Output : Requirement Specification Document


Idea : Reflects a mutual understanding between
client and developer of the work to be completed


Provides the basis for
acceptance testing

(did we
create the right system?)

Characteristics


Unambiguous


Complete


Verifiable


Consistent


Modifiable


Traceable


Useable

Stages


Feasibility Study


Requirements Analysis


Requirements Definition


Requirements Specification

Feasibility Study


Evaluates the ability to satisfy user needs using
current software and hardware technologies and
the constraints of the user’s organization (like
manpower, budgetary constraints)

Requirements Analysis


Provides a statement of the requirements of the
problem


Analyzes the current situation


States the goals of the system being developed
(cut costs, reduce errors, etc.)


Answers are acquired via interviews, observations,


Read by : client managers, end users, client
engineers, contractors, development architects

Q in RA


Who is involved and what are their background


What is the current system (equipment constraints)


What functions will be incorporated?


When must the system be completed? (schedule)


What is the impact on personnel, training, etc.


Why is the new system being developed?


What are the constraints in terms of cost?

Requirements Specification


Details what the system will do


Determines what the operational constriants are



It should


Completely specify technical requirements


Specify constraints and functions


Specify what should be done in exceptional
cases


Specify performance requirements

RS Document



Objective


Should state all functions to be performed


State all the constraints that affect the system


Provide testable criteria for acceptance


List qualities of the desired system


State default conditions


State error conditions and their resolutions


States only external system behavior (WHAT
the system does)

Contents of the paper


Introduction including general goals


Documentation of the current system


Current physical system


Current logical system


Data dictionary of current system


File structure for the current system

Contents of the system


Documentation of the proposed system


Proposed physical system


Proposed logical system


Functional specifications (services to be provided)


Data dictionary for the proposed system


File structure for the proposed system


Non
-
functional requirements (constraints)


Feasibility includes estimates of time, money and
personnel


System evolution assumptions (changes and their
resolutions)

Contents of the system


Glossary


Sign Off


Preliminary user manual (primarily screens)