Professional Documents
Culture Documents
Outline
Nature of software projects Engineering approaches Software process A process step Characteristics of a good process Waterfall model for development Other models Project planning
2
Software Systems
Ubiquitous, used in variety of applications
Business, engineering, scientific applications
Simple to complex, internal to public, single function to enterprise-wide, one location to distributed, batch or real-time, informational to missioncritical, .
3
Quite different from one-time programs where author and user are same ! 4
engineering a solution:
To design, develop (build, fabricate) an artifact that meets specifications efficiently, cost-effectively and ensuring quality Using scientific principles. 8
Engineering
Requires well-defined approach : repeatable, predictable Large projects requires managing the project itself
Manage people, money (cost), equipment, schedule Scale makes big difference: compare building a hut, 2storeyed house, or 50storeyed apartment building
Large Projects
Involve different types of people
Large building : architect, civil engineer, electrical engineer, workers (masons, carpenters), .
Large projects
Many deliverables : architecture plan, model, structure diagrams, electrical cabling layouts, Standards, regulations, conventions need to be followed Steps, milestones defined and reviews are carried out; progress is visible Project planning and project management essential
11
Software projects
Software is different from other products
Cost of production concentrated in development Maintenance consists of making corrections and enhancing or adding functions Progress in development is difficult to measure
12
14
Software Process
Process consists of activities/steps to be carried out in a particular order Software process deals with both technical and management issues Consists of different types of process Process for software development: produces software as end-result
multiple such processes may exist a project follows a particular process
15
Process Types
Process for managing the project
defines project planning and control effort estimations made and schedule prepared resources are provided feedback taken for quality assurance monitoring done.
16
Process Types
Process for change and configuration mgmt.
Resolving requests for changes Defining versions, their compositions Release control
17
Multiple processes
A large software development company may have multiple development processes
A. For client-server based conventional
applications (sales processing, payroll) B. For enterprise-level (ERP) projects based on packages and customization C. For web-based e-commerce type D. For data-warehousing/decision-support type
Step in a Process
Each step has a well-defined objective Requires people with specific skills Takes specific inputs and produces well-defined outputs Step defines when it may begin (entry criteria) and when it ends (exit criteria) Uses specific techniques, tools, guidelines, conventions.
19
Process step
Step must be executed as per project plan that gives duration, effort, resources, constraints, etc. It must produce information for management so that corrective actions can be taken
E.g., adding more resources
20
Process step
(entry criteria) actions to be carried out Review V&V (exit criteria)
inputs
outputs
21
Should be precisely defined no ambiguity about what is to be done, when, how, etc. It must be predictable can be repeated in other projects with confidence about its outcome
Predictable with respect to effort, cost:
Project A: Web-based library applications done by 3 persons in 4 months another project B (guest house bookings), similar in complexity should also take about 12 22 person months.
A Good Process
Predictable for quality: with respect to number and type of defects, performance,
Predictable process is said to be under statistical control , where actual values are close to expected values It supports testing and maintainability
Maintenance by third party Follow standards, provide necessary documentation
23
A Good Process
Facilitates early detection of and removal of defects
Defects add to project cost Late detection/correction is costly
It follows specify, design, build sequence that is intuitively obvious and appears natural
25
Waterfall Model
Produces many intermediate deliverables, usually documents
Standard formats defined Act as baseline used as reference (for contractual obligations, for maintenance) Important for quality assurance, project management, etc.
It is widely used (with minor variations) when requirements are well understood
26
Waterfall Model
system engineering -software part of some larger system -establish requirements for all elements of the system; assign some to software -understand information domain, functions, performance Analysis Project planning and interfacing. Project plans made design -translate requirements into s/w architecture, data structures and procedural details. A detailed design step can be added -programming -test logic and function interfaces -deployment; make changes for -Errors, performance -changes in requirement
code
27
Project plan and feasibility report Requirements document (SRS : Software Requirement Specifications) System design document Detailed design document Test plans and test reports Source code Software manuals (user manual, installation manual) Review reports
28
Cost/Effort Distribution
Total accumulated cost
Problem Feasibili Analysis System Detailed Impleme Mainten definitio ty study design design nn tation ance
Accumulated cost increases dramatically as programmers, operators, technical writers and computer time is committed. Cost of discovering and fixing errors also increases with steps
29
Requirements may not be clearly known, especially for applications not having existing (manual) counterpart
Railway reservation: manual system existes, so SRS can be defined On-line container management for railways - new Knowledge management for a central bank new
30
Shortcomings
Requirements change with time during project life cycle itself
Users may find solution of little use Better to develop in parts in smaller increments; this is common for packages, system software
Considered documentation-heavy: so much documentation may not be required for all types of projects.
31
Prototyping Model
When customer or developer is not sure
Of requirements (inputs, outputs) Of algorithms, efficiency, human-machine interaction
A throwaway prototype built from currently known user needs Working or even paper prototype
32
Prototyping
Quick design focuses on aspects visible to user; features clearly understood need not be implemented Prototype is tuned to satisfy customer needs
Many iterations may be required to incorporate changes and new requirements
33
Prototyping benefits
Misunderstandings between software users and developers are exposed Missing services may be detected and confusing services may be identified A working system is available early in the process The prototype may serve as a basis for deriving a system specification The system can support user training 34 and system testing
Types of prototyping: Throwaway prototyping Evolutionary prototyping or breadboard prototyping Incremental prototyping Extreme prototyping
35
Prototyping process
Establish p ro to ty pe o bjectives Define p ro to ty pe fun ction ality Develo p pro to ty pe Ev alu ate p ro to ty pe
Ou tline d efinition
Ex ecutab le pro to ty pe
36
Prototyping
Requirements gathering Quick design
build prototype
Engineer product
37
Advantages : Reduced time and costs Improved and increased user involvement Users are actively involved in the development Quicker user feedback is available leading to better solutions. Errors can be detected much earlier as the system is mode side by side.
38
Limitations of Prototyping
Customer may want prototype itself ! Developer may continue with implementation choices made during prototyping
may not give required quality, performance, .
Good tools need to be acquired for quick development May increase project cost
39
Iterative Development
Useful for product development where developers define scope, features to serve many customers Early version with limited feature important to establish market and get customer feedback Initial version may follow any method A list of features for future versions maintained Each version is analyzed to decide 40 feature list for next iteration
Specification
Outline description
Development
Intermediate versions
Validation
Final version
41
Evolutionary Development..
Main characteristics:
The phases of the software construction are interleaved Feedback from the user is used throughout the entire process The software product is refined through many versions
Evolutionary Development
Advantages:
Deals constantly with changes Provides quickly an initial version of the system Involves all development teams
Disadvantages:
Quick fixes may be involved Invisible process, not well-supported by documentation The systems structure can be corrupted by continuous change
43
Evolutionary Development
Disadvantages [contd]:
Special tools and techniques may be necessary The client may have the impression the first version is very close to the final product and thus be less patient
Applicability:
When requirements are not well understood When the client and the developer agree on a rapid prototype that will be thrown away Good for small and medium-sized software systems
44
Rq i e e t e ur mns s e i ic t n p cf aio
C mo e t o p nn a a ss n ly i
Rq i e e t e ur mns m d ic t n o if aio
S s m ei n yte d sg w hr u e it e s
Dv lo mn ee p et a di te r to n n gai n
Ss m y te v li aio adt n
45
46
47
Applicability:
When there is a pool of existing components that could satisfy the requirements of the new product Emerging trend: integration of web services from a range of suppliers
48
Spiral Model
Activities are organized in a spiral having many cycles Four quadrants in each cycle
1. Determine objectives, Alternatives, constraints 2. Evaluate alternatives, identify and handle risks
49
Spiral Model
Prototyping, simulations, benchmarking may be done to resolve uncertainties/risks Development step depends on remaining risks; e.g.,
Do prototype for user interface risks Use basic waterfall model when user interface and performance issues are understood but only development risk remains
50
52
Spiral Model
Main characteristics:
Also a hybrid model that support process iteration The process is represented as a spiral, each loop in the spiral representing a process phase Four sectors per loop: objective setting, risk assessment and reduction, development and validation, planning Risk is explicitly taken into consideration
53
Spiral Model
Advantages:
Risk reduction mechanisms are in place Supports iteration and reflects real-world practices Systematic approach
Disadvantages:
Requires expertise in risk evaluation and reduction Complex, relatively difficult to follow strictly Applicable only to large systems
Applicability:
Internal development of large systems
54
In cep t i o n E l ab o rat i o n
C o n s t ru ct i o n
Tran s i t i o n
55
Elaboration phase
Detailed use cases, analysis, architecture design, detailed plan, preliminary user manual
Construction phase
Detailed design, components, test plans/cases, implementation, detailed manuals
Transition phase
56 Delivery, beta/acceptance, user feedback
57
Summary
Challenges in software development and need for engineering approach
Step-by-step methodology with specific deliverables
Precise definition of a step Waterfall model : natural, widely followed in spite of its limitations Project management for planning, monitoring and control
58