beit 381 se lec 5, 6, 7 & 8 - 69 - 12 feb21,22,28,29 - sw process 1-3 sdlc models
Post on 18-May-2015
483 Views
Preview:
DESCRIPTION
TRANSCRIPT
SE-381 Software Engineering
BEIT-VLecture no. 5
Software Engineering Processes1 of 3
Quality Product
• For a quality software product, both the quality of product itself and quality of software process are important.
• The cost of error recovery in the later phases of software is many times more than in earlier phases, so more attention should be paid in the earlier phases, and these should be made error-free.
Boehm 1987 - ‘Industrial Sw Metrics Top 10 List’1. Finding and fixing a Sw problem after delivery, costs 100 times more than
finding and fixing the problem in early design phases2. You can compress Sw development schedule 25% of nominal, but no
more3. For every $1 you spend on development, you will spend $2 on
maintenance4. Sw Development and maintenance costs are primarily a function of the
number of SLOC or DLOC – Delivered Lines of Code5. Variations among people account for the biggest differences in Sw
productivity6. The overall ratio of Sw : Hw costs is still growing, in 1955 it was 15:85, in
1985, 85:15 {and in 2011 it is almost 95:5}7. Only 1/6th or about 15 -16% of sw development effort is devoted to
programming8. Sw products typically cost 3 times as much per SLOC as individual Sw
programs, Sw systems (i.e. system of systems) cost 9 times as much Sw programs (Sw pgm : Sw Product : Sw Sys :: 1:3:9)
9. Walkthroughs catch 60% of the errors10. 80% of the contribution comes from 20% of the contributors – Corollary
of Pareto Law
Pareto Analysis or Principle
In any series of elements to be controlled, a selected, small fraction, in terms of the numbers of elements, always accounts for a large fraction in terms of effect.
– Vilfredo Pareto (1848-1923) – an economist and sociologist
Pareto Analysis or Principle implies
• Focus on the problem and try to identify “the vital or significant few versus the trivial many”
• Few examples
– Only a small percentage of the thousands of inventory items in a department store account for 80% of the dollar sales (large stores capitalize on this)
– Less than10% of employees in an organization will account for most of the absenteeism
– A few percent of the kinds of illnesses are the cause of admission for a great majority of hospital patients
– Steve M Erickson (1981); Management Tools for Everyone: Twenty Analytical Techniques That Are Easy to Learn and Valuable to Know; Petrocelli Books Inc. New York, USA
– A detailed analysis of patients revealed that 80% of common diseases, like fever, cough, cold etc are ‘minor’ diseases and can be cured by educating masses about hygiene
– Dr Ijaz Bashir, Chairman, Decent Welfare Society, Gujrat, Pakistan – Sept 2010– Some figures from Proceedings of the Seminar on CORPORATE
AGRICULTURE: ISSUES & OPTIONS; UAAR (2001)• 93% people own 37% of the land whereas the rest 7% own 63% of the land• Over 80% of the farmers either own less than 2 hectors of land or are landless
tenants• Over 70% of the land holdings are below 12.5 acres• Less than 6% own over 60 hectors of land
• 1 Hectare = 10,000 m2 and 1 acre = 4840 Yards2 = 4047 m2
Maintenance Aspects
– 1970s Development-then-Maintenance Model+ Well defined two stages- Changing Application Environments- Every product developed from Scratch - No reuse
– Maintenance is a process that occurs when‘Software undergoes modifications to code and associated documentation due to a problem or the need of improvement or adaptation’ [ISO/IEC ‘95]
• For every 1$ spent on development, 2$s are spent on maintenance• In 1992, 60%-80% of R & D staff at HP was involved in
Maintenance, and Maintenance constituted 40-60% of the total cost of Software [Colman et al 1994]• Organizations devote upto 80% of their time and effort
to maintenance [Yourdon 1996]• Maintenance is an extreme phase, so techniques
efficient for Maintenance result in overall saving
Maintenance Aspects (Contd.)
Failure Curve for Hardware
Software doesn’t wear out but it deteriorates
Idealized and Actual Failure Curve for Software
Increased Failure rate due to side effects and corrections or bug fixes madeSoftware Engineering methods strive to reduce the magnitude of the spikes and the slope of the actual curve
Software ProcessIs a set of activities and associated results which produce a Software Product. These activities are carried out (mostly) by humans, using different tools (including CASE tools) and predefined methods.
The main four fundamental activities which are common to all Sw processes are:Specification, Development, Validation and Evolution.
There exist a number of Sw Processes, initiated by different individuals and organizations. Different processes can be used to develop the same product, but they do have their own specificities.
Software Processes
Software Process ..
To introduce visibility in the process different graphical notations are used to produce different design documents. Since different methods have different origins, so these are different and have different notations for their deliverable documents. Now effort is being made to unify them.
Different metrics have been devised to control and optimize the software process to produce ‘Quality’ product.
Paradigm or MethodologyIs collection of consistent methods used to support all activities or phases of software development life cycle. Each phase being the part of the process, has its own inputs and deliverables, so these need to conform, semantically and as well as in notations.
Software Process and Its Components
Software Process
Product Engineering Processes
Process Management Process
Development Process
Project Management Process
Software Configuration Process
Characteristics of Software Process
• Process should be – Predictable– Support Testability and Maintainability – Support Change– Early Error or Defect Removal– Process Improvement and Feedback
SE-381 Software Engineering
BEIT-VLecture no. 6
Software Engineering Processes2 of 3
Software Paradigms
• Classical or Structured Paradigm• Data Structures and Behavior is loosely connected• Data Structures are identified using Entity Relationship and
Attribute Analysis• Behavior of the system is understood by analyzing the data flow
with in the system, among different data structures. Data Flow Diagrams are used to portray this transition of data
• Functions performed by the system are resolved into different strongly-cohesive and loosely-coupled modules
• Modules and their interaction are presented in Structure Charts, and their functionality is written in un-ambiguous ‘structured English’
• The system is considered as a whole – one lump.
• Object Oriented Paradigm• Is a new way of thinking about problems using models organized
around real-world concepts• Fundamental construct is Object, which combines Data structure
and behavior in one entity (Encapsulation)• Software is collection of discrete objects• OO approach exploits the four characteristics – Identity,
Classification, Polymorphism and Inheritance• Users functional requirements are represented thru Use Case
Diagrams, Classification of objects represented using Class Diagrams, interaction of different objects and Classes is shown using Sequence Diagrams, all activities are shown using Activity Diagrams, etc.
• There are different methodologies which support OO paradigm for all/some phases of software development
• Object Modeling Technique (OMT) is one such methodology which supports from Requirement phase thru Design and Implementation phases to Maintenance phase of the SDLC
Software Paradigms .
Client, User & Developer
• ClientWho initiates and pays for the product and effort incurred therein, can be a person or an organization
• UserPerson(s) who will be using the product, on Client’s behalf
• DeveloperPerson(s) involved in any of the phases of software development, from Analysis to Implementation and Testing
Personal / Groups Involved in SD• Developers
Software Analysts, Architects, Designers, Programmers or Coders, Testers, Document Writers etc
• Project ManagersLooking after the execution of software project, it includes planning, monitoring and control and termination phases
• Configuration ControllersInvolved in Configuration Control or Sw Configuration Management Process
• SQA Division or SectionSolely responsible for assuring quality of the produced products, directly reporting to CEO. Has qualified members having expertise in all Software development areas
• SQA GroupSoftware Quality Assurance group will be responsible for assuring quality of the product at a particular phase or stage. Depending upon product size, its composition (and size) could vary for each phase, must of at least 4-5 members, representatives from Client, previous stage, current stage and next stage, should be headed by an experienced person from SQA division
• Software Engineering Process Group (SEPG)Involved in managing the managing the Process Management Process activities
Re-Cap• For efficiency and cost effectiveness– Software should be developed using a phased process– Testing and Maintenance being two very costly phases, so to
benefit for maximum saving these two phases should be focused
– Errors introduced in early stages, if not identified and eradicated early then these cost a lot
HenceIntegrated Approach to Software Development should be adopted, according to this at each stage testing should be carried out [Jalote05] calls it ETVX Approach, whereas [Schach96] specifies What needs to be tested at each stage!!!
Desired Process Properties
• Provide high Quality and Productivity (Q&P)– Support testability as testing is the most expensive
task; testing can consume 30 to 50% of total development effort
– Support maintainability as maintenance can be more expensive than development; over the life of the product, up to 80% of total cost
– Remove defects early, as cost of removing defects increases with latency
ETVX Specification
• ETVX approach is to specify at each phase or step– Entry criteria: what conditions must be satisfied for
initiating this phase– Task: what is to be done in this phase– Verification: the checks done on the outputs of this
phase– eXit criteria: when can this phase be considered
done successfully• A phase also produces information for
management
ETVX approach
Testing at Different Phases of Software Development
• Main Testing TypesTesting could be of Two Types; Non-executable and Executable
• PhasesRequirements Phase , Specification Phase, Planning Phase, Design Phase
Implementation Phase, Integration Phase, Maintenance Phase and Retirement Phase
Ref: Stephen R. Schach (2007); Software Engineering, 7th Edition, Tata McGraw-Hill Publishing Company Limited, New Delhi
Requirements Phase
• Input– Clients (and Users) tell what
they want– Client’s description of project– Meetings to understand
‘what they want’– Client believes the Sw will
help him– Find out the ‘constraints’
• Problems– Client don’t know
what he wants– Description is vague,
ambiguous, contradictory or simply impossible to achieve
– Clarify the time and budget constraints
Requirements Phase
• Do– Clarify the constraints, refine
‘What Client wants’ and ‘what is needed’
– Meetings with development team to address constraints
– Analyze the possible problem areas
– Rapid Prototyping helps
– Requirements Document finalized
• Testing– SQA group should
ensure the Clients needs are satisfied
– Confirm the final version of Rapid Prototype is acceptable to Client/User and meets their needs
– Safeguard ‘moving target problem’
Specification Phase
• Input– Requirements Doc
• Goal– Specification Doc
should explicitly describe• Functionality• Constraints and• Input/Output of the
product
• Problems– Specification Doc is the basis
for the Contract, so must be• Precise• Unambiguous• Clear• No Contradictory or multi-
meaning statements– In case of lawsuits it works as
an evidence
Specification Phase
• Do– Consult Client whenever
needed to clarify the requirements
– Write clearly avoiding mentioned problems
– Validate errors in the input data and ensure all cases are covered
– Specification (Software Requirements Specification – SRS) Document finalized
• Testing– SQA group should ensure
Specification Doc is• Complete• Unambiguous• Non-contradictory
– Ascertain that the promised functionality can be delivered and it’s true reflection of clients requirements
• Review of joint team from Client and Developer and SQA group helps
SE-381 Software Engineering
BEIT-VLecture no. 7
Software Engineering Processes3 of 3
Planning Phase• Input
– Specification Doc– Resources Available– Organizational structure– SDLC,CASE Tool, Detailed
Schedule for Budget• Purpose
– Exact Time and Budget Estimates
– Erroneous estimates may lead to loss of contract or financial penalty to Company.
• How to Do:– All Specification
Document functions are addressed and estimated
– Task Assignments to personnel
– Time estimates, Costs incurred, detailed schedules
Planning Phase
• Outputs– Major Components of the
product, • Milestones / Gantt Charts• Time & Cost Budget• Deliverables and their
timelines
– Software Project Management Plan• With who is doing what and
when information
• Testing– Validate that Time
and Budget estimates are correct
– A good way to do it, obtain two alternate plans from different teams and note the differences and reconcile
– Formal Review is another good technique to test
Design PhaseThe Most Important Phase– Specification describes
‘What’ and Design tells ‘How’ the functionality can be provided
– Design is a CREATIVE activity• Input– Specification / SRS
Document• How Done– Determine the Internal
Structure of the product
– Decide for Algorithms and Data Structures
– Determine I/O of the product from SRS Doc
– Analyze Internal Data Flows
– Decompose Product into ‘Modules’
– Specify ‘functionality’ and ‘Interface’ to each module
– Record all design decisions explicitly
Design Phase• Design has 2 or 3 Parts
– Architectural Design • Break Down of System into
Subsystems, Components and modules of the product• Structure Charts to represent
– Detailed Design• Functionality and Interface of
all modules is developed• Algorithms and Data
Structures of each module identified
• Testing– Re-trace – That every
function in Spec (SRS) Doc have a module supporting it and the vice versa
– Test Cases written for all modules be validated with the Spec Doc i.e. they conform to specs.
Implementation Phase• Input
– Detailed Design for all the modules
– Test Cases for the respective modules
• How to Do– Consider language
and platform dependencies here, if any
– Code the modules with sufficient comments
– Provide extra documentation like decision trees/tables, flow-charts etc for maintenance
• Testing– Test all the modules
using already prepared test cases
• Output– Code for Modules
Integration Phase
• Input– Specifications of
Modules, Subsystems, and System; Test Cases, Structure Chart(s), Modules’ Code
• How to Do– Top-Down, Bottom-
up or incremental integration
• Testing– Module, sub-systems and system
all perform according to the specifications,
– Product testing– Acceptance testing at Clients
site, – Shrink-wrapped products –
alpha, beta testing
Test Cases Results with Used/produced I/O, Source Code, Acceptance Test proof
Maintenance Phase • Maintenance starts after
delivery!!
• But – Maintenance must be kept in
focus while Designing/Coding …
– Should be integral part of Software Development process
• Testing– Ensure proper documentation– Careful change insertion and
Regression Testing i.e. after making a change run all test cases to ensure that no further error has been introduced.
Up-to-Date ‘Change Document’, Regression Test results
Retirement Phase• When to Retire?
– Further Maintenance is not Cost-effective
– Write-Only code– The documentation has
rendered Obsolete– Hardware Advancement
• Like a ‘record in sports’ new record improves the old one
• True retirement is Rare in Sw domain, it is always a replacement, with improved version
• Testing / Utility– A complete review of
functionality and operations the Sw performed
– Incorporation of keynote functions into the replacement
References / Reading Assignment
[Jal97/05] Pankaj Jalote (1997,2005); An Integrated Approach to Software Engineering; 2nd /3rd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes pp:21-66
[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle Models
[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping
The relevant parts of the above chapters to be read at home.
SE-381Software Engineering
BEIT-VLecture no. 8
Software Process Models1 of 3
Software Process Models– Software Development
• Needs to be performed in a series of well-defined steps, so that the process could be managed to develop fault-free software product in the given budgetary and time constraints
– Software Process Model • is a way or the order in which these steps/stages or phases of
software development are executed,• is a framework for portraying the specific sequence of these
phases
There are a number of Software Process Models
Some Software Process Models– Build-n-Fix Model– Classical Waterfall Model and its variants– Prototyping Models
• Rapid or Throwaway Prototyping Model• Evolutionary Prototyping Model
– Incremental Model– Risk Based Models
• Spiral Model– eXtreme Programming– Synchronise and Stabilize Model– Object Oriented Life Cycle Models
• Fountain Model• Agile Model• Unified Process Model
Build and Fix Model
• Pros– Simplest– Used by students for
classroom assignments– Build-use-modify-use-modify
cycle continues until client is satisfied
• Cons– No specification or design
stages– Works for very small (<300-
400 LOCs) codes– Unreliable product– Very high cost of the
produced product– Maintenance is in fact not
possible without specification and design documents
Build and Fix Model
A Software Development Life Cycle Model must be chosen before the work on the product is initiated
Waterfall Model• Pros
– Oldest, Since 1970s– Found by Winston Royce in
1970– Most Widely used (in
Aerospace Industry, even today)
– Divides complex task into smaller, more manageable tasks and executes them in Linear order
– Each task/stage is well defined has deliverables and well specified inputs and outputs
– Iterations accommodated in Modified version
– ‘Something is better than nothing’ - at least a systematic method then a haphazard approach
– Project Management Possible
Waterfall ModelMany organizations still cling to the waterfall model because, even with its shortfalls, it provides the most fully elaborated management guidelines on how to proceed in a given software situation.
Barry Boehm, April 1998
Although 20 years back problems in WF model approach were highlighted but still 40% of companies using this approach –
IEEE Software 2003 survey [Som04]
Classical Waterfall Model
Stage-wise Inputs / Outputs
Waterfall Model with Inter-stage Feedback
Jal97 – Waterfall Model
Waterfall Model
Waterfall Model .• Problems
– Real-life systems don’t work in a simple sequential mode (so Iterations implemented)
– Problems CROP UP in the later stages effecting earlier stages
– Uncertainty in user specification CANNOT be specified at the outset
– Design errors are numerous and persistent
– Software delayed, user has to wait for long time
– Specifications frozen at early stages, so the product may NOT conform to what user wanted
Waterfall Model ..
Thus limitations of WF model are:– Requirements of a system are frozen before design begins; could
work for automation of a legacy system but not for new systems– Freezing of Requirements may include the choice of HW, so on
completion the new system may be dependent on a obsolete technology, as technology is ever improving
– WF Model stipulates that the requirements are completely specified before the SD can proceed. In reality, for many systems including COTs a part of the system is fully developed and sold to customers, and then functionality is added to the system and it is redeveloped
– Early freezing of specifications and absence of not many iterations, can not guarantee Users Satisfaction
– The ‘Document Driven’ nature of Waterfall Model has its own Pros & Cons
Prototyping Model
• Can be used to clarify Requirements, to design Use Interface, demonstrate feasibility, verify the new technology will work, or to provide a training system• Cannot be used for embedded software, real-time
control software or scientific or Engineering numerical computational software• Tools for developing good quick prototypes are
scarce, some HLLs are providing routine libraries, whereas systems like Smalltalk could not survive or capture markete
Prototyping Model
• Ensures that customer gets what s/he wanted• Customer is provided a working version of software i.e.
prototype at a very early stage• Customer plays with it and suggests needed
amendments and developer incorporates them into the prototype• User/customer needs/requirements are thus refined
and defined, and the software could be developed using these requirements
Prototyping ModelPrototyping Model could be of two types:• Rapid or Throwaway prototype Model• Evolutionary Prototype Model
Rapid or Throwaway Prototyping ModelUses rapid techniques to construct prototypes that are thrown away once users’ requirements have been established
Evolutionary Prototyping ModelEvolves the initial prototype into the final software as the requirements are clarified
Prototyping Model
Pressman (1992) – SEPA3
Prototyping Model• Problems & Real-life
– Prototyping is a historical technique of Engineering Discipline, Chemical Engg, Aerodynamics
– User not aware what he wants
– Developer not sure how good his Algorithms or Code would perform
– Client ignorant of expected output. Changes to come by use of the Sw Product
• Different Types– Paper Prototype– PC Based Screen layouts– Software developed to
initiate User Interaction with the system
• How Done– Client & Developer meet
and sort out Requirements– A quick design– Implementation– User Feedback
accommodation
Prototyping Model .
• Cons• The developed Prototype should not be taken as Product• According to Brooks 1975, it should be a ‘Throwaway Version’ of
the product but is it possible?• Customer Pressure to take Prototype as Product, and Developer
Shortcuts to get the Prototype working• Should be used as a tool for Requirement Phase
• Client be explained at the outset that after getting Prototype accepted the ‘Product’ will be re-engineered.
Rapid Prototyping Model
Jal97 – Prototyping Model
[Bel05] Throwaway Prototype Model
Rapid Prototyping Model• Pros
– A new model, using the developed Prototype as a Front-end to your SD process, to gather – User
Requirements,– Clients’
experience with the Sw (Prototype)
– Insight to the Algorithms used and how efficient these are
– A tool/guide for all who are involved in SD of the product to improve their area
• Prototype used as– A tool for
Requirements phase
• Rest Follow the remaining phases linearly
• Iteration introduced by– Maintenance phase, for
– Corrective– Adaptive and– Perfective changes
[Bel05] Evolutionary Prototype Model
Evolutionary Versus Rapid Prototypes
– Rapid Prototypes start from incomplete specifications, go through a ‘quick’ design and development and these are improved on users’ or clients’ response. The final output is the clarified Requirements. These are used to develop the system
– Evolutionary Prototypes start from initial specifications, designed thoroughly and incorporate the users’/clients’ response. The evolved system turns out to be the final system
Prototyping Model – An Example
Problem Statement
Write a software program that can check the general knowledge of a user, specifically his/her knowledge about geography and history of Pakistan and its neighbors.
This is to be used by general public, so its implementation in national language will be preferred.
References
[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping
[Jal97] Pankaj Jalote (1997); An Integrated Approach to Software Engineering; 2nd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes
[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle Models
The relevant parts of the above chapters to be read at home.
top related