This action might not be possible to undo. Are you sure you want to continue?
Requirements Analysis Extracting the requirements of a desired software product is the first task in creating it. While customers probably believe they know what the software is to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements. Specification Specification is the task of precisely describing the software to be written, in a mathematically rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already welldeveloped, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable. Software architecture The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.
Coding Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion. Testing Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer. Documentation An important task is documenting the internal design of software for the purpose of future maintenance and enhancement. Documentation is most important for external interfaces. Maintenance Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About 2/3 of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs.
System development approach, depending Upon the specific requirement of the organization in the total system may follow Any one of the following models :
Waterfall model Prototyping model Spiral model
The combination of more than one of the Above model may be used for system Development, depending upon the nature and size of the project and the risk involved. This Is called hybrid approach of system Development
The best-known and oldest process is the waterfall model, where developers follow these steps in order. They state requirements, analyze them, design a solution approach, architect a software framework for that solution, develop code, test (perhaps unit tests then system tests), deploy, and maintain. After each step is finished, the process proceeds to the next step, just as builders don't revise the foundation of a house after the framing has been erected. If iteration is not included in the planning, the process has no provision for correcting errors in early steps , so the entire (expensive) engineering process may be executed to the end, resulting in unusable or unneeded software features.
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
All requirements must be known upfront Deliverables created for each phase are considered frozen – inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development – iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)
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.
Prototyping is the process of quickly putting together a working model in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process, where it is believed to reduce project risk and cost. Often one or more prototypes are made in a process of incremental development where each prototype is influenced by the performance of previous designs, in this way problems or deficiencies in design can be corrected
ENGINEER THE PRODUCT
Developers build a prototype during the requirements phase Prototype is evaluated by end users Users give corrective feedback Developers further refine the prototype When the user is satisfied, the prototype code is brought up to the standards needed for a final product.
Prototyping Model Steps
A preliminary project plan is developed An partial high-level paper model is created The model is source for a partial requirements specification A prototype is built with basic and critical attributes The designer builds the database user interface algorithmic functions The designer demonstrates the prototype, the user evaluates for problems and suggests improvements. This loop continues until the user is satisfied
Can be used when customer is not sure about what he wants Faster way of finalising the requirements Useful for new technologies and domains A prototype if used in a production environment, may lack quality Overall maintainability may be overlooked The customer may want the prototype delivered. Process may continue forever (scope creep)
Spiral Model Steps
The spiral model is a Systems Development Life Cycle methodology that combines features of prototyping with the waterfall methodology. The spiral model is often favored for large, complex projects. Iterates cycles of these project phases: 1 Requirements definition 2 Risk analysis 3 Prototyping 4 Simulate, benchmark 5 Design, implement, test 6 Plan next cycle (if any)
Steps in the spiral model The new system requirements usually involves include: of usersare defined. Thisthe end users of the interviewing a number representing all
system. A preliminary system design is created. An initial prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the final product’s characteristics. After evaluating the strengths, weaknesses and risks of the first prototype, a second prototype is developed and tested. If the risk is considered to be too great, the client may choose to terminate the project at this point. Risk factors to be considered include development cost overruns, operating-cost miscalculation, etc. Subsequent prototypes are developed until the customer is satisfied that the latest prototype represents the desired product. The system is constructed, based on the final prototype. The final system is evaluated and tested. Routine maintenance is carried out continually to prevent large-scale failures and to minimize downtime.
Advantages of Spiral Model 1. Avoidance of Risk is enhanced. 2. Strong approval and documentation control. 3. Implementation has priority over functionality. 4. Additional Functionality can be added at a later date. Disadvantages of Spiral Model 1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule 4. Possibility to end up implemented as the Waterfall framework
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)
Incremental SDLC 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.
ITERATIVE ENHANCEMENT MODEL
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 High
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.