Software Development life cycle models

Software Development life cycle models

SDLC A framework that describes the activities performed at each stage of a software development project. The development process defines what to do and when to complete and the order of tasks. A software lifecycle model is a standardised format for planning , organising, and running a new development project. It defines the Project specific parameters which includes size, (person-years),Budget,Duration. project plan = lifecycle model + project parameters Within the product lifecycle, software will undergo maintenance to correct errors and to comply with changes to requirements.

Typical Phases in Software Development
Feasibility Feasibility study Implementation Strategy planning Component Requirements Elicitation Integration Testing Statement Installation Analysis System Operations Maintenance Detailed Support Design System Retirement Detailed (C) Dr. Ernest Cachia

Activities During Phases
Requirements: establish the customer’s needs System Design: develop the system’s structure Detailed Design: develop module structures Implementation: code or otherwise Testing: check what’s been developed Installation: bring the system into production Maintenance: correct, adapt, improve (C) Dr. Ernest Cachia

Classifications of SDLC Model
Sequential Iterative Waterfall V Model Progressive

b. Waterfall Model Requirements Specification Architectural Design
Detailed Design Code and Unit Testing Software Integration System Integration Acceptance Testing

Different Phases of Sequential Model :
Requirements phase - in which the requirements for the software are gathered and analyzed, to produce a complete and unambiguous specification of what the software is required to do Detailed Design phase - where the detailed implementation of each component is specified. Code and Unit Test phase - in which each component of the software is coded and tested to verify that it faithfully implements the detailed design. Software Integration phase - in which progressively larger groups of tested software components are integrated and tested until the software works as a whole. System Integration phase - in which the software is integrated to the overall product and tested. Acceptance Testing phase, where tests are applied and witnessed to validate that the software faithfully implements the specified requirements. Software specifications will be products of the first three phases of this lifecycle model. The remaining four phases all involve testing the software at various levels, requiring test specifications against which the testing will be conducted as an input to each of these phases.

Waterfall Strengths Easy to understand, easy to use
Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

disadvantages Idealised, doesn’t match reality well.
Doesn’t reflect iterative nature of exploratory development. Unrealistic to expect accurate requirements so early in project Software is delivered late in project, delays discovery of serious errors. Difficult to integrate risk management Difficult and expensive to make changes too documents. Significant administrative overhead, costly for small teams and projects

When to use the Waterfall Model
Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform.

3. Iterative Model Requirements Design Review Implementation and Test An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model.

3. Iterative Model - Phases
Requirements phase, in which the requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase which produces a complete and final specification of requirements. Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design. Implementation and Test phase, when the software is coded, integrated and tested. Review phase - in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed

Rapid Application Model (RAD)
Requirements planning phase (a workshop utilizing structured discussion of business problems) User description phase – automated tools capture information from users Construction phase – productivity tools, such as code generators, screen generators, etc. inside a time-box. (“Do until done”) Cutover phase -- installation of the system, user acceptance testing and user training.

RAD Strengths Reduced cycle time and improved productivity with fewer people means lower costs Time-box approach mitigates cost and schedule risk Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code. Uses modeling concepts to capture information about business, data, and processes.

RAD Weaknesses Accelerated development process must give quick responses to the user Risk of never achieving closure Hard to use with legacy systems Requires a system that can be modularized Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.

When to use RAD Reasonably well-known requirements
User involved throughout the life cycle Project can be time-boxed Functionality delivered in increments High performance not required Low technical risks System can be modularized

The Unified Process Booch, Jacobson, and Rumbaugh later developed the unified process, which is a framework for object-oriented software engineering using UML Draws on the best features and characteristics of conventional software process models Emphasizes the important role of software architecture Consists of a process flow that is iterative and incremental, thereby providing an evolutionary feel Consists of five phases: inception, elaboration, construction, transition, and production

Phases of the Unified Process
Elaboration Inception planning modeling communication construction Construction deployment Transition Production

Inception Phase Encompasses both customer communication and planning activities of the generic process Business requirements for the software are identified A rough architecture for the system is proposed A plan is created for an incremental, iterative development Fundamental business requirements are described through preliminary use cases A use case describes a sequence of actions that are performed by a user

Elaboration Phase Encompasses both the planning and modelling activities of the generic process Refines and expands the preliminary use cases Expands the architectural representation to include five views Use-case model Analysis model Design model Implementation model Deployment model Often results in an executable architectural baseline that represents a first cut executable system The baseline demonstrates the viability of the architecture but does not provide all features and functions required to use the system 21

Construction Phase Encompasses the construction activity of the generic process Uses the architectural model from the elaboration phase as input Develops or acquires the software components that make each use- case operational Analysis and design models from the previous phase are completed to reflect the final version of the increment Use cases are used to derive a set of acceptance tests that are executed prior to the next phase 22

Transition Phase Encompasses the last part of the construction activity and the first part of the deployment activity of the generic process Software is given to end users for beta testing and user feedback reports on defects and necessary changes The software teams create necessary support documentation (user manuals, trouble-shooting guides, installation procedures) At the conclusion of this phase, the software increment becomes a usable software release 23

Production Phase Encompasses the last part of the deployment activity of the generic process On-going use of the software is monitored Support for the operating environment (infrastructure) is provided Defect reports and requests for changes are submitted and evaluated 24

Software Process Models: Evolutionary Development…

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 Types of evolutionary development: Exploratory development Throw-away prototyping

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 system’s structure can be corrupted by continuous change 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

Incremental model

Incremental model Construct a partial implementation of a total system
Then slowly add increased functionality The incremental model prioritizes requirements of the system and then implements them in groups. Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.

Incremental Model Strengths
Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses “divide and conquer” breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced

Incremental Model Weaknesses
Requires good planning and design Requires early definition of a complete and fully functional system to allow for the definition of increments Well-defined module interfaces are required (some will be developed long before others) Total cost of the complete system is not lower

When to use the Incremental Model
Risk, funding, schedule, program complexity, or need for early realization of benefits. Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology

Spiral model

Spiral Quadrant Determine objectives, alternatives and constraints
Objectives: functionality, performance, hardware/software interface, critical success factors, etc. Alternatives: build, reuse, buy, sub-contract, etc. Constraints: cost, schedule, interface, etc.

Spiral Quadrant Evaluate alternatives, identify and resolve risks
Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight schedules, poor process, etc. Resolve risks (evaluate if money could be lost by continuing system development

Spiral Quadrant Develop next-level product
Typical activities: Create a design Review design Develop code Inspect code Test product

Spiral Quadrant Plan next phase
Typical activities Develop project plan Develop configuration management plan Develop a test plan Develop an installation plan

Spiral Model Strengths
Provides early indication of insurmountable risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently

Spiral Model Weaknesses
Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during non-development phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

When to use Spiral Model
When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration)

Agile Software Development
Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Agile methods also emphasize working software as the primary measure of progress

Agile Software Development: Intro
Characteristics of Agile Software Development -- Light Weighted methodology -- Small to medium sized teams -- vague and/or changing requirements -- vague and/or changing techniques -- Simple design -- Minimal system into production

Characteristics Modularity Iterative Time-bound Incremental Convergent
People-oriented Collaborative

Agile model

Disadvantages Agile is difficult as It Requires more TESTING & active CUSTOMERS involvement. Agile is More disciplined. The code may be integrated continuously, sometime after every update in source code repository. Needs teams and self-discipline More Planning is needed Since the planning is done frequently (for each iteration), and the plan is updated as and when needed more focused planning needs to be done. The plan has to be adaptive to meet the changing requirements.

Software What Is Software?
Computer software is the product that software professionals design and build. It encompasses Programs Content Documents

Vehicle to deliver the product
Information Produces Modifies Manages Displays Software - the Product Acquires Transforms Software Vehicle to deliver the product Operating System Network Software Case tools

What is Software Engineering
Solving Problems Software products are large and complex Development requires analysis and synthesis Analysis: decompose a large problem into smaller, understandable pieces abstraction is the key Synthesis: build (compose) a software from smaller building blocks composition is challenging

Con.. The analysis process

Con.. The synthesis process

What is Software Engineering Solving Problems (continued)
Method: refers to a formal procedure; a formal “recipe” for accomplishing a goal that is typically independent of the tools used Tool: an instrument or automated system for accomplishing something in a better way Procedure: a combination of tools and techniques to produce a product Paradigm: philosophy or approach for building a product (e.g., OO vs structured approaches)

What is Software Engineering Where Does the SW Engineer Fit in
What is Software Engineering Where Does the SW Engineer Fit in? (continued) Relationship between computer science and software engineering

Characteristics Software does not wear out
It becomes reliable over time. It becomes obsolete based on new changes Software is not manufactured One time development efforts Continuous maintenance efforts. Reusability of components Not a single product as a whole Every component – Single process Component based Software Engineering Software is flexible Can be made flexible Leads to unpredictability

The Evolving Role of Software
Software takes on a dual role: A product Delivers the computing potential embodied by computer hardware The vehicle for delivering a product Acts as the basis for the control of the computer (OS), the communication of information (networks), and the creation and control of other programs (software tools and environments) The most important product: Information

Changing Nature of Software
System software Application software Engineering/scientific software Embedded software Product-line software (e.g., inventory control, word processing, multimedia) Web applications Artificial intelligence software Ubiquitous computing (small, wireless devices) Netsourcing (net-wide computing) Open source (operating systems, databases, development environments) The ".com" marketing applications

Types of Software System software Real-time software Business software
it services other programs heavy interaction with hardware, Real-time software data gathering component analysis component monitoring component Business software largest single software area MIS important component Engineering and scientific software number crunching numerical algorithms

Types of Software Embedded software PC software Web-based software
resides in read-only memory of any appliances controls products and system for consumers PC software several hundreds of applications available as software packages Web-based software unlimited software resource AI software makes use of non-numerical algorithms expert systems, pattern recognition, games

Software Myths - Management
"We already have a book that is full of standards and procedures for building software. Won't that provide my people with everything they need to know?" Not used, not up to date, not complete, not focused on quality, time, and money "If we get behind, we can add more programmers and catch up" Adding people to a late software project makes it later Training time, increased communication lines "If I decide to outsource the software project to a third party, I can just relax and let that firm build it" Software projects need to be controlled and managed

Software Myths - Customer
"A general statement of objectives is sufficient to begin writing programs – we can fill in the details later" Ambiguous statement of objectives spells disaster "Project requirements continually change, but change can be easily accommodated because software is flexible" Impact of change depends on where and when it occurs in the software life cycle (requirements analysis, design, code, test)

Software Myths - Practitioner
"Once we write the program and get it to work, our job is done" 60% to 80% of all effort expended on software occurs after it is delivered "Until I get the program running, I have no way of assessing its quality Formal technical reviews of requirements analysis documents, design documents, and source code (more effective than actual testing) "The only deliverable work product for a successful project is the working program" Software, documentation, test drivers, test results "Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down" Creates quality, not documents; quality reduces rework and provides software on time and within the budget 

Software Planning

Problem Projects: Needs quantitative estimates and organized plan.
Requirement changes as the project proceeds Important to define 1. Definition of problem 2. Scope of problem 3. Decomposition of problem

Software Scope First activity in Project Management
It can be the answers of 1. Context: How to make the system fit for all levels? What are the constraints for the same? 2. Information Objectives: What visible objects are projected as output. What input is required for the same. 3. Function and Performance: Regular functions (Input to Output) Special functions

Problem Decomposition
Defined as Partitioning Sits at the core of Requirement analysis. Two major areas: 1. Functionality – needs to be delivered. 2. The process – to deliver the same. Software functions – evaluated in the beginning Cost, Schedule estimation – based on decomposition Some degree of decomposition – always good.

Software Metrics Measurement can be applied • to the software process with the intent of improving • to assist in estimation, quality control, productivity assessment, and project control • to help assess the quality of technical work products and to assist in tactical decision making as a project proceeds

MEASURES , METRICS , AND INDICATORS
a measure provides a quantitative indication of the extent, amount, dimensions, capacity, or size of some attribute of a product or process. a metric as " a quantitative measure of the degree to which a system, component, or process possesses a given attribute”. an indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself . A software engineer collects measures and develops metrics so that indicators will be obtained .

Project indicators enable a software project manager to assess the
status of an ongoing project track potential risks uncover problem areas before they "go critical“ adjust work flow or tasks evaluate the project team's ability to control quality of software engineering work products.

Cont…

Project Metrics Used for strategic purposes
by a project manager and a software team to adapt project work flow and technical activities . Project metrics on estimation effort and time duration estimates Production rates –pages of documentation, –review hours, –function points, –delivered source lines

Con.. The intent of project metrics is twofold :
–to minimize the development schedule, –to assess product quality on an ongoing basis and when necessary, modify the technical approach to improve quality. Every project should measure: Inputs - measures of the resources (e.g., people, environment) required to do the work Outputs - measures of the deliverables or work products created during the software engineering process Results - measures that indicate the effectiveness of the deliverables

SOFTWARE MEASUREMENT Direct measures (e.g., the length of a bolt) Indirect measures (e.g., the "quality" ) Direct measures –lines of code (LOC) –execution speed –memory size –defects reported over some set period of time Indirect measures ·functionality, quality, complexity, efficiency, reliability, ·maintainability and many other "abilities"

Size-Oriented Metrics Derived by normalizing quality and or productivity measures by considering the "size" of the software

Con.. A set of simple size -oriented metrics can be developed for each project: errors per KLOC (thousand lines of code) defects per KLOC $ per LOC pages of documentation per LOC other interesting metrics: errors/person-month LOC per person-month $/page of documentation

Function-Oriented Metrics
Use a measure of the functionality delivered by the application as a normalization value. Function-oriented metrics were first proposed by Albrecht.

Con.. Number of user inputs. Each user input that provides distinct application oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately. Number of user outputs. Each user output that provides application-oriented information to the user is counted. In this context output refers to reports, screens, error messages, and so on. Individual data items within a report are not counted separately. Number of user inquiries. An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted. Number of files. Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file), is counted. Number of external interfaces. All machine readable interfaces (e.g., data files on tape or disk) that are used to transmit information to another system are counted.

COMPUTING FUNCTION POINTS
Once the above data have been collected, a complexity value is associated with each count. For determining whether a particular entry, –simple, –average, –complex. To compute function points (FP), FP = count-total x [ x SFi] The Fi ( i = 1 to 14) are "complexity adjustment values"

Con…

Con.. 2. Are data communications required?
1. Does the system require reliable backup and recovery? 2. Are data communications required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilized operational environment? 6. Does the system require on-line data entry? 7. Does the on-line data entry require the input transaction to be built over multiple screens or operations? 8. Are the master files updated on-line? 9. Are the inputs, outputs, files, or inquiries complex? 10.. Is the internal processing complex? 11. Is the code designed to be reusable? 12. Are conversion and installation included in the design? 13. Is the system designed for multiple installations in different organizations? 14. Is the application designed to facilitate change and ease o f use by the user?

Feature point metrics FP doesn’t solve algorithmic complexity of a software. It implies that developing efforts of two functionally same programs are same. To resolve the same, feature point is proposed. It includes additional parameter – algorithmic complexity. More complexity of the function – greater efforts to develop it. These are language independent and easily computed from SRS document.

Software Estimation Determine size of the product. From the size estimate, determine the effort needed. From the effort estimate, determine project duration, and cost.

Software Cost Estimation

Three approaches Empirical Heuristic Analytical

Cost Estimation Techniques
Empirical techniques: An educated guess based on past experience. Heuristic techniques: Assume that the characteristics to be estimated can be expressed in terms of some Mathematical expression. Analytical techniques: Derive the required results starting from certain simple assumptions.

Empirical Estimation Techniques
Expert Judgement: A guess made by an expert. Suffers from individual bias. Delphi Estimation: Overcomes some of the problems of expert judgement.

Expert Judgment Technique
Experts divide a software product into component units: e.g. GUI, database module, data communication module, billing module, etc. Add up the guesses for each of the components. Subject to human errors and individual bias. Experts may overlook some factors. Understanding all the aspects would be difficult.

Delphi Estimation Team of Experts and a coordinator.
Experts carry out estimation independently. Mention the rationale behind their estimation. Coordinator notes down any extraordinary rationale. Circulates among experts. Experts re-estimate. Experts never meet each other To discuss their viewpoints.

Heuristic – COCOMO Model
COCOMO (COnstructive COst MOdel) proposed by Boehm. Divides software product developments into 3 categories: Organic Semidetached Embedded

Con.. Elaboration of Product classes
Organic: Development of well understood appl. Program. Size is very small. Team members develop similar applications. Semidetached: If it contains the mix of experienced and inexperienced staff. Embedded: The software is strongly coupled to complex hardware, or real-time systems.

Con.. Software cost estimation is done through three stages:
Basic COCOMO, Intermediate COCOMO, Complete COCOMO.

Basic COCOMO Model Gives only an approximate estimation:
Effort = a1*(KLOC)a2 Tdev = b1*(Effort)b2 KLOC is the estimated kilo lines of source code, a1,a2,b1,b2 are constants for different categories of software products, Tdev is the estimated time to develop the software in months, Effort estimation is obtained in terms of person months (PMs).

Development Effort Estimation
Organic : Effort = 2.4*(KLOC)1.05 PM Semi-detached: Effort = 3.0*(KLOC)1.12 PM Embedded: Effort = 3.6*(KLOC)1.20 PM

Development Time Estimation
Organic: Tdev = 2.5*(Effort)0.38 Months Semi-detached: Tdev = 2.5*(Effort)0.35 Months Embedded: Tdev = 2.5*(Effort)0.32 Months

Con. Development time sub linear function of product size.
When product size increases two times, development time does not double. Time taken: almost same for all the three product categories.

Con.. Development time is roughly the same for
all the three categories of products: For example, a 60 KLOC program can be developed in approximately 18 months regardless of whether it is of organic, semidetached, or embedded type. There is more scope for parallel activities for system and application programs, than utility programs.

Intermediate COCOMO Basic COCOMO model assumes
effort and development time depend on product size alone. However, several parameters affect effort and development time: Reliability requirements Availability of CASE tools and modern facilities to the developers Size of data to be handled

Con.. For accurate estimation,
the effect of all relevant parameters must be considered: Intermediate COCOMO model recognizes this fact: refines the initial estimate obtained by the basic COCOMO by using a set of 15 cost drivers (multipliers).

Con.. If modern programming practices are used,
initial estimates are scaled downwards. If there are stringent reliability requirements on the product : initial estimate is scaled upwards. Rate different parameters on a scale of one to three: Depending on these ratings, multiply cost driver values with the estimate obtained using the basic COCOMO

Computer: Execution time, storage requirements, etc.
Cost driver classes: Product: Inherent complexity of the product, reliability requirements of the product, etc. Computer: Execution time, storage requirements, etc. Personnel: Experience of personnel, etc. Development Environment: Sophistication of the tools used for software development.

Shortcomings of two models
Both models: consider a software product as a single homogeneous entity: However, most large systems are made up of several smaller sub-systems. Some sub-systems may be considered as organic type, some may be considered embedded, etc. for some the reliability requirements may be high, and so on.

Complete COCOMO A Management Information System (MIS) for an
organization having offices at several places across the country: Database part (semi-detached) Graphical User Interface (GUI) part (organic) Communication part (embedded) Costs of the components are estimated separately: Summed up to give the overall cost of the system.

Con.. A Management Information System (MIS) for an
organization having offices at several places across the country: Database part (semi-detached) Graphical User Interface (GUI) part (organic) Communication part (embedded) Costs of the components are estimated separately: summed up to give the overall cost of the system.

The Activities of the Analysis Phase

Activities of the Analysis Phase and Their Key Questions
Systems Analysis and Design in a Changing World, 3rd Edition

Techniques for Information Gathering
Analysis phase done to understand business functions and develop system requirements Original structured approach Create model of existing system Derive requirements from existing system model Current approach Identify logical requirements for new system Balance the review of current business functions with new system requirements

Information Gathering and Model Building

Fact Finding Methods Review existing reports, forms, and procedure descriptions Interview and discussion processes with users Observe and document business processes Build prototypes Distribute and collect questionnaires Conduct joint application design (JAD) sessions Research vendor solutions

Review Existing Reports, Forms, and Procedure Descriptions
Source: External industry wide professional organizations and trade publications Source: Existing business documents and procedure descriptions within organization Identify business rules, discrepancies, and redundancies Be cautious of outdated material Obtain preliminary understanding of processes Use as guidelines / visual clues to guide interviews

Analyzing Procedures and Other Documents
Types of information to be discovered: What problems exist with the existing system Are there opportunities to meet new needs What’s the organizational direction? Who are the “key stakeholders What are the values of the organization Are there any special information processing circumstances What’s the history of the current system design Are there rules for processing data

Analyzing Procedures and Other Documents (cont.)
Four types of useful documents Written work procedures Describes how a job is performed Includes data and information used and created in the process of performing the job or task Business forms Explicitly indicate data flow in or out of a system Reports Enables the analyst to work backwards from the report to the data that generated it Descriptions of current information system

Written work procedure is a business document that formally describes work processes, provides useful information regarding system functionality and logic.

Observe and Document Business Processes
Varies from office walkthroughs to performing actual tasks Not necessary to observe all processes at same level of detail May make users nervous, so use common senseCan document workflows with UML activity diagrams

On-site Observations Objective: To get as close as possible.
Performed by the analyst for knowledge gain. Analyst should listen more than talk. Analyst should approach the things with genuine interest. Should not enter into arguments. Four alternative methods: 1. Natural or Contrived 2. Obtrusive or unobtrusive 3. Direct or indirect 4. Structured or unstructured

Conduct Interviews and Discussions with Users
Effective way to understand business functions and rules Time consuming and resource expensive May require multiple sessions to Meet all users Understand all processing requirements Can meet with individuals or groups of users List of detailed questions prepared

What is Interviewing? Dialogue with user or manager to obtain their requirements Two forms: Open-ended: conversational, questions with no specific answers in mind Closed-ended: structured, questions with limited range of possible answers

Guidelines for Effective Interviewing
Plan the interview. Prepare interviewee: appointment, priming questions. Prepare agenda, checklist, questions. Listen carefully and take notes (tape record if permitted). Review notes within 48 hours. Be neutral. Seek diverse views.

Interview Step 1: Determine the People to Interview
Informal structures Step 2: Establish Objectives for the Interview Determine the general areas to be discussed List the facts you want to gather

Interviews Step 3: Develop Interview Questions
Creating a standard list of interview questions helps to keep you on track and avoid unnecessary tangents Avoid leading questions Open-ended questions Closed-ended questions Range-of-response questions

Interviews Step 4: Prepare for the Interview
Careful preparation is essential because interview is an important meeting and not just a casual chat Limit the interview to no more than one hour Send a list of topics Ask the interviewee to have samples available

Interviews Step 5: Conduct the Interview
Develop a specific plan for the meeting Begin by introducing yourself, describing the project, and explaining interview objectives Use engaged listening Allow the person enough time to think about the question After interview, summarize the session and seek a confirmation

Interviews Step 6: Document the Interview
Note taking should be kept to a minimum After the interview, record the information quickly After the interview, send memo expressing appreciation, including the main points discussed so the interviewee has a written summary and can offer additions or corrections

Interviews Step 7: Evaluate the Interview Unsuccessful Interviews
In addition to recording the facts obtained in an interview, try to identify any possible biases Unsuccessful Interviews No matter how well you prepare for interviews, some are not successful

Issue with Individual Interviews
Advantages Easier to schedule than group interviews Disadvantages Contradictions and inconsistencies between interviewees Follow-up discussions are time consuming Only one at a time

Group Interviews Interview several key people together Advantages
More effective use of time Can hear agreements and disagreements at once Opportunity for synergies Disadvantages More difficult to schedule than individual interviews

Sample Checklist to Prepare for User Interviews

Questionnaire Steps Selecting participants Designing the questionnaire
Using samples of the population Designing the questionnaire Careful question selection Administering the questionnaire Working to get good response rate Questionnaire follow-up Send results to participants

Distribute and Collect Questionnaires
Limited and specific information from a large number of stakeholders. Preliminary insight into business Not well suited for gathering detailed information Closed-ended questions direct person answering question Open-ended questions encourage discussion and elaboration

Good Questionnaire Design
Begin with non-threatening and interesting questions Group items into logically coherent sections Do not put important items at the very end of the questionnaire Do not crowd a page with too many items Avoid abbreviations Avoid biased or suggestive items or terms Number questions to avoid confusion Pretest the questionnaire to identify confusing questions Provide anonymity to respondents

Types No response direction or specific response.
Open ended Questions: No response direction or specific response. Only questions with space provided for the answers. Closed Questions: Fill-in-blanks Dichotomous(Yes/No) type Ranking scales Multiple choice questions Multiple choice with rating

Advantages It is economical and requires less skill.
It can be administered to large numbers simultaneously. Standardized wording and order of the questions and standardized instruction for reporting responses. The respondents feel greater confidence in the anonymity of a questionnaire. Less pressure on subjects for immediate responses. Respondents have time to think the questions .

Build Prototypes Preliminary working model of a larger, more complex system component Discovery, design, evolving prototypes Prototype should be Operative Working model to provide “look and feel” Focused to accomplish single objective Quick Built and modified rapidly with CASE tools

Prototyping Quickly converts requirements to working version of system
Once the user sees requirements converted to system, he will ask for modifications or will generate additional requests Most useful when: User requests are not clear Few users are involved in the system Designs are complex and require concrete form History of communication problems between analysts and users Tools are readily available to build prototype

Basic steps for prototyping
Identify the user’s information and operating requirements. Develop a working prototype that focuses on only the most important functions, using a basic data base. Allow the user to use the prototype, discuss requested changes, and implement the most important changes. Repeat the next version of the prototype with further changes incorporated until the system fully meets user requirements.

Joint Application Design (JAD)
Intensive group-oriented requirements determination technique Team members meet in isolation for an extended period of time Highly focused Resource intensive Started by IBM in 1970s

Joint Application Design Facilities
Conducted in special room Limit interruptions May be off-site Resources Overhead projector, white board, flip charts, work material Electronic support (laptops) CASE tools Group support systems (GSS)

The JAD Session Tend to last 5 to 10 days over a three week period
Prepare questions as with interviews Formal agenda and groundrules Facilitator activities Keep session on track Help with technical terms and jargon Record group input Help resolve issues Post-session follow-up

Managing Problems in JAD Sessions
Reducing domination Encouraging non-contributors Side discussions Agenda merry-go-round Violent agreement Unresolved conflict True conflict Use humor

Joint Application Development
JAD Advantages and Disadvantages Advantages Allows key users to participate effectively When properly used, JAD can result in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system Disadvantages More expensive and can be cumbersome if the group is too large relative to the size of the project

Validating the Requirements
Two basic approaches to validating requirements Predictive development Requirements assumed stable and feasible Requirements specified and validated beforehand Adaptive development Requirements are assumed difficult to document Requirements subject to change System prototypes used in validation process

Validating the Requirements (continued)
Structured walkthrough Reviews findings Reviews models based on findings Objective: find errors and problems Purpose: ensure that model is correct Conducting structured walkthrough Preparation Execution Follow-up

Scheduling walkthroughs
Walkthroughs should be conducted frequently Focuses on a specific and small piece of work Increases the likelihood of uncovering errors Before author has too great an ego investment Scheduled only when the author is ready About 4 or 5 people Advanced preparation (no more than 2 hours) should be required of and performed by each reviewer.

Conducting Walkthroughs
Coordinator chairs the meeting Walkthrough structure Author's overview? Reviewers should be able to understand the product without assistance Author's overview may "brainwash" reviewers into making the same logical errors as did the author Author's detailed walkthrough Based on logical arguments of what the design or code will do at various stages Requested specific test cases Coordinator resolves disagreements when the team can not reach a consensus

Walkthroughs: Guidelines
Set an agenda and keep to it Limit debate and rebuttal Identify problem areas, but don't attempt to solve every problem Limit the number of participants Insist upon advance preparation Train reviewers Develop a checklist for each reviewable product

Types of Walkthroughs Specification walkthroughs Design walkthroughs
System specification Project planning Requirements analysis Design walkthroughs Preliminary design Design Code walkthroughs Test walkthroughs Test plan Test procedure Maintenance reviews

Specification Walkthroughs
Objective - Check the system specification for: Problems Inaccuracies Ambiguities Omissions Participants User Senior analyst Project analysts Objects DFDs, Data Dictionary, ERDs, ...

Design Walkthroughs Objective - Check the architecture of the design for: Flaws Weaknesses Errors Omissions Participants User Analyst Senior designer Project designers Objects Structure charts, detailed design documents, ...

Feasibility Analysis Feasibility – the measure of how beneficial or practical an information system will be to an organization. Feasibility analysis – the process by which feasibility is measured. Creeping Commitment – an approach to feasibility that proposes that feasibility should be measured throughout the life cycle. No additional notes.

Six Tests For Feasibility
Operational feasibility – a measure of how well a solution meets the system requirements. Cultural (or political) feasibility - a measure of how well a solution will be accepted in an organizational climate. Technical feasibility – a measure of the practicality of a technical solution and the availability of technical resources and expertise. Schedule feasibility – a measure of how reasonable the project timetable is. Economic feasibility - a measure of the cost-effectiveness of a project or solution. Legal feasibility - a measure of how well a solution can be implemented within existing legal/contractual obligations. Conversion Notes Cultural (or political) feasibility and legal feasibility are new to the seventh edition. Teaching Notes It is useful to take an example information system and explain how it might fail each test of feasibility. For example, a payroll system might fail legal feasibility for a multi-national corporation faced with national laws regarding the exportation of employee data. Emphasize that all candidates should be analyzed according to all of the above criteria. Students should understand that rarely will any one candidate solution be the most feasible candidate according to all criteria.

Operational Feasibility: The PIECES Framework
Performance -- Does current mode of operation provide adequate throughput and response time? Information -- Does current mode provide end users and managers with timely, pertinent, accurate and usefully formatted information? Economy -- Does current mode of operation provide cost-effective information services to the business? Could there be a reduction in costs and/or an increase in benefits? Control -- Does current mode of operation offer effective controls to protect against fraud and to guarantee accuracy and security of data and information? Efficiency -- Does current mode of operation make maximum use of available resources, including people, time, flow of forms,...? Services -- Does current mode of operation provide reliable service? Is it flexible and expandable?

Con.. How do end-users and managers feel about the problem (solution)?
It's not only important to evaluate whether a system can work but also evaluate whether a system will work. A workable solution might fail because of end-user or management resistance. Does management support the project? How do the end-users feel about their role in the new system? What end-users or managers may resist or not use the system? People tend to resist change. Can this problem be overcome? If so, how? How will the working environment of the end-users change? Can or will end-users and management adapt to the change?

Cultural (or political) feasibility
Does management support the system? How do end users feel about their role in the system? What end users may resist or not use the system? How can this be overcome? How will the working environment change? Can users and management adapt to the change? Conversion Notes This is a new slide in the seventh edition.

Technical feasibility
Is the proposed technology or solution practical? Do we currently possess the necessary technology? Do we possess the necessary technical expertise? Technical feasibility assesses whether the current technical resources are sufficient for the new system. If they are not available, can they be upgraded to provide the level of technology necessary for the new system. Conversion Notes This is a new slide in the seventh edition.

Project Risk Factors Project size Project structure Development group
Team size, organizational departments, project duration, programming effort Project structure New vs. renovated system, resulting organizational changes, management commitment, user perceptions Development group Familiarity with platform, software, development method, application area, development of similar systems User group Familiarity with IS development process, application area, use of similar systems

High technical familiarity mitigates risk due to project size and structure. Low familiarity increases risk.

Cultural (or political) feasibility
Does management support the system? How do end users feel about their role in the system? What end users may resist or not use the system? How can this be overcome? How will the working environment change? Can users and management adapt to the change? Conversion Notes This is a new slide in the seventh edition.

Legal feasibility Copyrights Union contracts
Legal requirements for financial reporting Antitrust laws National data and work laws Conversion Notes This is a new slide in the seventh edition.

Economic feasibility During Scope Definition During Problem Analysis
Do the problems or opportunities warrant the cost of a detailed study and analysis of the current system? During Problem Analysis After a detailed study of the current system Better estimates of development costs and benefits During Decision Analysis Requirements now defined Development costs can be better estimated Conversion Notes This is a new slide in the seventh edition.

Economic Feasibility Cost-benefit analysis: identify all the financial benefits and costs associated with a project Tangible vs. intangible benefits Tangible vs. intangible costs One-time vs. recurring costs

Tangible Benefits Benefits that can be measured in dollars and with certainty

Benefits that cannot easily be measured in dollars or with certainty

Types of Costs Tangible Costs: can be measured in dollars and with certainty Intangible Costs: cannot easily be measured in dollars or with certainty One-time Costs: often associated with project start-up and development or systems start-up Recurring: a cost associated with ongoing evolution and use of a system

Possible Project Costs
Procurement Consulting, equipment, site preparation, capital, management time Start-up Operating systems, communications installation, personnel hiring, organizational disruption Project-related Application software, software modification, personnel overhead, training, data analysis, documentation Operating System maintenance, rental, asset depreciation, operation and planning

One-time Costs

Recurring Costs

Three Popular Techniques to Assess Economic Feasibility
Payback Analysis Return On Investment Net Present Value Teaching Notes While the textbook covers only the above popular techniques, it is important to stress that there may be others that organizations choose to use in assessing the economic feasibility of an investment. Stress the importance of determining the investment decision-making process or techniques used by the organization. It should also be pointed out that sometimes the techniques vary according to the individuals involved.

Payback Analysis Payback analysis – a technique for determining if and when an investment will pay for itself. Payback period – the period of time that will lapse before accrued benefits overtake accrued and continuing costs. No additional notes.

Present Value Formula Present value – the current value of a dollar at any time in the future. PVn = 1/(1 + i)n Where n is the number of years and i is discount rate Discount rate – a percentage similar to interest rates that you earn on your savings. In most cases the discount rate for a business is the opportunity cost of being able to invest money in other projects or investments Teaching Notes While you may want your students to know this formula, be sure to emphasize that PV tables are available and spreadsheets generally include a PV function. Point out that the lifetime of an investment may be dictated by an organization and its investment decision makers. Point out that the interest rate is often dictated. Many companies choose to use the current prime rate.

Return-on-Investment Analysis (ROI)
Return-on-Investment (ROA) analysis – a technique that compares the lifetime profitability of alternative solutions. The ROI for a solution or project is a percentage rate that measures the relationship between the amount the business gets back from an investment and the amount invested. Lifetime ROI = (estimated lifetime benefits – estimated lifetime costs) / estimated lifetime costs Annual ROI = lifetime ROI / lifetime of the system No additional notes.

Software Reliability Definition: The probability of failure-free operation of the software for a specified period of time in a specified environment.

Software Reliability Trustworthiness or dependability.
Probability of the product working correctly over a given period of time. Not only depends on the number of errors but also on the exact location of the error. It is also depends on the execution profile. Observer dependant Cannot be determined absolutely.

What is Reliability? Reliability is a broad concept.
It is applied whenever we expect something to behave in a certain way. Reliability is one of the metrics that are used to measure quality. It is a user-oriented quality factor relating to system operation. Intuitively, if the users of a system rarely experience failure, the system is considered to be more reliable than one that fails more often. A system without faults is considered to be highly reliable. Constructing a correct system is a difficult task. Even an incorrect system may be considered to be reliable if the frequency of failure is “acceptable.” Key concepts in discussing reliability: Fault, Failure, Time

What is Reliability? Failure
A failure is said to occur if the observable outcome of a program execution is different from the expected outcome. Fault The cause of failure is called a fault. Example: A failure may be cause by a defective block of code. Time Time is a key concept in the formulation of reliability. If the time gap between two successive failures is short, we say that the system is less reliable. Two forms of time are considered. Execution time () Calendar time (t) What is Reliability?

Factors Influencing Software Reliability
A user’s perception of the reliability of a software depends upon two categories of information. The number of faults present in the software. The ways users operate the system. This is known as the operational profile. The fault count in a system is influenced by the following. Size and complexity of code Characteristics of the development process used Education, experience, and training of development personnel Operational environment

Applications of Software Reliability
Comparison of software engineering technologies What is the cost of adopting a technology? What is the return from the technology -- in terms of cost and quality? Measuring the progress of system testing Key question: How of testing has been done? The failure intensity measure tells us about the present quality of the system: high intensity means more tests are to be performed. Controlling the system in operation The amount of change to a software for maintenance affects its reliability. Thus the amount of change to be effected in one go is determined by how much reliability we are ready to potentially lose. Better insight into software development processes Quantification of quality gives us a better insight into the development processes. Applications of Software Reliability

Reliability metrics Probability of failure on demand (POFOD):
This is a measure of the likelihood that the system will fail when a service request is made POFOD = means 1 out of 1000 service requests result in failure Relevant for safety-critical or non-stop systems

Con.. Rate of fault occurrence (ROCOF)
Frequency of occurrence of unexpected behaviour ROCOF of 0.02 means 2 failures are likely in each 100 operational time units Relevant for operating systems, transaction processing systems

Con.. Mean time to failure
Measure of the time between observed failures MTTF of 500 means that the time between failures is 500 time units Relevant for systems with long transactions e.g. CAD systems

Con.. Availability Measure of how likely the system is available for use. Takes repair/restart time into account Availability of means software is available for 998 out of 1000 time units Relevant for continuously running systems e.g. telephone switching systems

Con.. Mean Time Between Failures(MTBF): Can combine MTTF and MTTR.
If MTBF indicates 300hours indicates that every failure occurs after 300hrs. Mean Time to Repair(MTTR): Once failure occurs, some time is required to fix the error. MTTR measures the average time to track the errors causing the failure and fix it.

Failure Classification
Transient - only occurs with certain inputs Permanent - occurs on all inputs Recoverable - system can recover without operator help Unrecoverable - operator has to help Non-corrupting - failure does not corrupt system state or data Corrupting - system state or data are altered

Reliability growth modelling
Growth model is a mathematical model of the system reliability change as it is tested and faults are removed Used as a means of reliability prediction by extrapolating from current data Depends on the use of statistical testing to measure the reliability of a system version

Equal-step reliability growth

Observed reliability growth
Simple equal-step model but does not reflect reality Reliability does not necessarily increase with change as the change can introduce new faults The rate of reliability growth tends to slow down with time as frequently occurring faults are discovered and removed from the software A random-growth model may be more accurate

Random-step reliability growth

Growth models choice Many different reliability growth models have been proposed No universally applicable growth model Reliability should be measured and observed data should be fitted to several models Best-fit model should be used for reliability prediction

Software Maintenance

What is Reverse Engineering ?
You have an unexpected case: You finished one course project using Java Your program runs OK But, by accident, you delete the java file How to hand in your project? Reverse Engineering

Reverse Engineering Analyzing software with a view to understanding its design and specification May be part of the reengineering process May be used to specify a system for prior to reimplementation Program understanding tools may be useful (browsers, cross-reference generators, etc.)

Forward Engineering Reverse Engineering Requirements Design Source Code Behavior

Abstraction System Reverse Engineering Abstraction Forward Engineering Re-Implementation Old system New System

What is Reverse Engineering?
RE encompasses any activity that is done to determine how a product works, to learn the ideas and technology that were used in developing that product. RE can be done at many levels RE generally belongs to Software Maintenance

Why do we need RE ? Recovery of lost information
providing proper system documentation Assisting with maintenance identification of side effects and anomalies Migration to another hw/sw platform Facilitating software reuse

Why do we need RE ? Benefits maintenance cost savings
quality improvements competitive advantages software reuse facilitation

Reverse Engineering Concepts part 1
Abstraction level ideally want to be able to derive design information at the highest level possible Completeness level of detail provided at a given abstraction level Interactivity degree to which humans are integrated with automated reverse engineering tools

Reverse Engineering Concepts part 2
Directionality one-way means the software engineer doing the maintenance activity is given all information extracted from source code two-way means the information is fed to a reengineering tool that attempts to regenerate the old program Extract abstractions meaningful specification of processing performed is derived from old source code

Reverse Engineering Process

Reverse Engineering Activities part 1
Understanding process source code is analyzed to at varying levels of detail system program component pattern statement to understand procedural abstractions and overall functionality

Reverse Engineering Activities part 2
Understanding data internal data structures database structure User interfaces what are the basic actions (e.g. key strokes or mouse operations) processed by the interface? what is a compact description of the system's behavioral response to these actions? what concept of equivalence of interfaces is relevant?

Difficulties of Reverse Engineering
Gap between problem /solution domain Gap between concrete and abstract Gap between coherency/disintegration Gap between hierarchical/associational

Scope and Task of Reverse Engineering
program understanding Problem/Application domain Mapping Program/Implemen. domain

Scope and Task of Reverse Engineering
Redocumentation and/or document generation Recovery of design approach and design details at any level of abstraction Identifying reusable components and components that need restructuring Recovering business rules Understanding high-level system description.

Maintenance Costs Usually greater than development costs (2* to 100* depending on the application) Affected by both technical and non-technical factors. Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult. Ageing software can have high support costs (e.g. old languages, compilers etc.)

Maintenance Costs (cont’d)
Time and money (software that costs £ 10 a line to develop costs £ 400 a line to maintain) Organizations become maintenance bound and cannot produce new software Customer dissatisfaction when seemingly legitimate requests for repair or modification cannot be addressed in a timely manner Reduction in overall software quality as changes introduce latent errors in the maintained software Upheaval caused during development efforts when staff must be “pulled” to work on a maintenance task

Maintenance Cost Factors
Team stability Maintenance costs are reduced if the same staff are involved with them for some time Contractual responsibility The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change Staff skills Maintenance staff are often inexperienced and have limited domain knowledge Program age and structure As programs age, their structure is degraded and they become harder to understand and change

Estimation of Maintenance Cost
Maintenance efforts – 60% of the total life cycle cost. It varies widely from one application domain to another. 2 to 4 times of the development cost. Boehm – MC estimation as a part of COCOMO. He defines it as a Annual Change Traffic (ACT).

Con.. ACT= KLOC(added) +KLOC(deleted) /KLOC(total).
KLOC(added) : Total kilo lined of source code added during maintenance. KLOC(deleted): Total KLOC deleted during maintenance. MC= ACT*Development cost. The results are approximate

Software Development life cycle models

Similar presentations

Presentation on theme: "Software Development life cycle models"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Software Development life cycle models

Similar presentations

Presentation on theme: "Software Development life cycle models"— Presentation transcript:

Similar presentations

About project

Feedback