the lifecycle of software l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 27

- PowerPoint PPT Presentation


  • 266 Views
  • Uploaded on

The “Lifecycle” of Software. Chapter 5 Lifecycle Models Many different lifecycle models Waterfall Spiral Exploratory Programming Opportunistic development Waterfall Model Stakeholders Needs Analysis System Requirements Analysis Architecture Design Detailed Design Coding

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '' - libitha


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
lifecycle models
Lifecycle Models
  • Many different lifecycle models
    • Waterfall
    • Spiral
    • Exploratory Programming
    • Opportunistic development
waterfall model
Waterfall Model

Stakeholders

Needs

Analysis

System

Requirements

Analysis

Architecture

Design

Detailed

Design

Coding

And Testing

System Testing

alternatives to the waterfall model
Alternatives to the Waterfall Model
  • The “Waterfall” model can mislead: boundaries between phases are not always distinct, nor are the “activies” in the phases strictly exclusive.
  • The Waterfall model is not the only model there is!
the spiral model
The spiral model
  • The “Sprial” model suggests that activities might be repeated: that is, during the software lifecycle there are several “waterfall” model cycles.
  • The software is finished only when a predefined level or risk has been satisfied!
spiral
Spiral

http://www.stsc.hill.af.mil/crosstalk/2001/05/boehm.html

exploratory programming
Exploratory programming
  • Exploratory programming is for the development of programs in environments where the requirements are volatile or there are no expert “customers”
  • As the requirements are explored using code, when a satisfactory product is achieved, the project is complete.
exploratory programming8

Develop Software Criteria

Build Software System

Use It

Deoiver It

Is it adequate

Exploratory Programming
opportunistic development
Opportunistic development
  • Opportunistic development is driven more by a business model, in which allocated resources drive the rate of development and activities.
  • Many times, resources are put on the most difficult problems first, leading to the nickname “hardest-part-first” development.
the phases of development
The Phases of Development
  • The phases of development are not exclusive. For instance, design can legitimately happen during the requirements phase.
  • Ideally, though, the activities reserved to other phases are kept to a minimum
  • The general phases are: requirements, specification, design, coding, and testing. (Maintenance is not included in this discussion, but be aware that it exists!)
requirements
Requirements
  • During the requirements phase, activities revolve around the definition of the problem.
  • These activities usually include interviews with end-users, recording requirements information, exploration of any existing workflows or systems, use-case identification, and so on.
specification
Specification
  • The specification phase involves translating the information from the requirements phase into a more structured form.
  • In addition, analysis usually takes place, which systematically explores the requirements for conflicts, or identifies missing or incorrect requirements.
  • The output of this phase is information suitable for partitioning into a design (and testing!)
design
Design
  • During design, a software architecture is developed, and the specified requirements are partitioned into the design.
  • The architecture can be developed formally (as in the case of SA/SD), or can be laid down based on experience acquired from developing similar systems.
  • The output from this phase is module specifications suitable for development of code.
slide14
Code
  • The coding phase translates the design (and as a result, the specification), into executable code.
  • The output from the coding phase is code suitable for testing. Typically, this means that it compiles, links, and satisfactorily passes a subset of sets, sometimes called a “smoke test.”
testing
Testing
  • Testing compares the developed code to the requirements and specifications, using a set of specifically designed tests.
  • The problems found during testing (defects, or “bugs”), are turned back over to the development team for correction, then the test activity begins again with the next release.
software inspection
Software inspection
  • One of the best ways to catch software defects is to find them before they are “built into” the system.
  • Software inspection provides a method for doing this.
  • Simply put, software inspection uses “many eyes” to check work as it is released for production.
inspection works
Inspection works
  • It has been demonstrated many times that software inspection traps defects early in the process.
  • Inspection can be used on every software artifact: requirements, specifications, design, code, and even tests.
the participants and the procedure
The participants and the procedure
  • Author: Producer of software artifact (code, specification, design, test, whatever).
  • Inspectors: Critical reviewers of artifact.
  • Recorder: Records comments from inspectors.
  • Moderator: Keeps the discussion “on topic”.
the participants and the procedure cont d
The participants and the procedure (cont’d)
  • Inspectors take turn critiquing a page, module, function, or whatever has been agreed upon as a “unit”. Recorder records inspectors comments.
  • Author may ask for elaboration or points, moderator make sure discussion doesn’t “escalate”.
  • Next instructor critiques the same page, and so on until all instructors have critiqued the “unit”.
  • The cycle begins again with the next page (or “unit.”)
inspection is expensive
Inspection is expensive
  • Inspection is “expensive” in resources.
  • Time is required to prepare the materials, study the materials, and attend the review.
  • Other activities must halt while the inspection activities occur.
what can an individual do
What can an individual do?
  • In the event that an entire “formal” inspection is prohibitive (four people minimum), alternative forms exist.
  • Work with another engineer to perform a scaled-down version of the inspection.
  • This can work if both engineers are experienced in inspection, and have a good handle on their ego, as well as a sensitivity to the other person’s feelings!
maintenance throughout the lifecycle
Maintenance Throughout the Lifecycle
  • “Maintenance” is “corrective” action: in essence, updating documents (and code) to fix defects.
  • The “defects” may be a changed requirement, design element, or test.
  • These changes can have an impact on may software artifacts, so they need to be updated, or “maintained.”
debugging
Debugging
  • Debugging can reveal problems that are really ‘bugs’ in the specification: it behaves exactly as specified, but it is wrong!
  • Inspections can also be considered “debugging”, and can also uncover design flaws, specification flaws, and so on.
configuration management
Configuration management
  • Configuration management is not just version control!
  • Configuration management outlines how a change moves through a review process, how changes to documents are made, and how changed documents are distributed!
  • This make sure every group has a chance to assess the impact of a change before it is made!
managing a development lifecycle
Managing a Development Lifecycle
  • Fundamental questions pop up during software development: Are we on track? Do we have enough people? What are the current issues and problems?
  • A few simple tools can help with some of these basic questions, and any software engineer can put these together at any time.
progress reports
Progress reports
  • Progress reports can be prepared by the individual or team to outline basic ‘status’.
  • These reports contain basic information essential to management: what was done this week, what is planned for next, and what obstacles have been encountered.
dividing effort among the phases
Dividing effort among the phases
  • Knowing how effort escalates during the development process, and knowing how this effort relates to the calendar is important for managers!
  • Remember, schedule is calendar-days, while effort is man-months (or weeks, or whatever.)
  • A man-month might well fit into a week: four engineers working for one-week (schedule) is a man-month (effort).