Software engineering
Upcoming SlideShare
Loading in...5
×
 

Software engineering

on

  • 415 views

 

Statistics

Views

Total Views
415
Views on SlideShare
415
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software engineering Software engineering Document Transcript

  • Software Engineering: Lecture 1: SDLC For developing systems/software that involves 10 Phases: 1. Initiation. 2. System Concept Development. 3. Planning. 4. Requirements Analysis. 5. Design. 6. Development. 7. Integration and Testing. 8. Implementation. 9. Operations and Maintenance. 10. Disposition. The Phases Initiation - Initiation is where there is an identified need for a new system. For instance, a retailer of fine crystal glass is in need of a new system to handle inventory.
  • They've decided that the old System of putting the inventory into a simple spreadsheet will no longer work. They want a system where they can track inventory, inventory cost, facilities cost, personnel, a customer database, can track trends in buying, identify inventory that is not moving well and price it to move, etc. In other words, they want to be able to know everything with a few clicks of the keyboard. A Project Management is placed in charge and he/she will develop a Concept Proposal - which is a document identifying the problem and why the new system needs to be pursued. The document is presented to upper management who approves it and the project moves on to the next phase. System Concept Development - This is where the first real look at what will be necessary takes place. Several reports can be created here. - Feasibility Study (will it work?) - Cost/Benefit Analysis (is the cost really worth it?) - System Boundary (how far should the project go?) - Risk Management (what will happen if we don't do it?) These reports are then presented, again, to the powers that be and a decision is made whether or not to go ahead. They approve the funding. If they give their approval it's on to the next phase. Planning Phase - Who is doing what, when, and how? What personnel are needed? Use existing personnel or hire consultants? New Hardware? Develop own software or buy it off the shelf? What are the Deliverables - such as completed software programming and documentation, user manual, training, testing plans, etc? A Planning document is submitted for approval. Requirements Analysis - Documentation of requirements. What interfaces are required (will it run with Windows NT and Windows XP?). What is the functionality required - should it be run with the mouse or keyboard commands? What is the level of proficiency required by the user? Will a new room be needed for the servers or equipment? Requirements documentation is approved, and then it's on to the Design phase.
  • Design Phase - Take those Requirements and develop detailed, workable specifications. This is where everything is put together and the actual design of the system is done. This is also where documentation such as the Maintenance Manual, Operations Manual, and Training Manual begin. This is also where some of the flaws in the original planning may appear and require some adjustment. Again, there is documentation and approval. Development Phase - The system is built. The software, hardware, and testing occur during the Development Stage. This is also the phase where the bugs are worked out of the system. A contingency plan is also developed at this point. A contingency plan is an emergency management document. If the power goes out - what happens to the system? What is the back up? How fast can it be brought back up to speed? Again, documentation and approval (get used to this). Integration and Testing Phase - This is the formal integration and testing of the system. Testing has been done on the development phase, but in the Integration and Testing Phase it is a formal, documented testing procedure, not only to assure that the system performs as designed, but testing the roll-out of the system. If there is already another system in place with data, how fast can that data be migrated into the new system and useable to the company? Usually, the system is rolled-out over a weekend so that if anything goes wrong, the old system is still active and available. Integration and Testing is vital to the decision to go "live" with the new system. If it fails testing, it cannot be trusted to work. Approval of testing and test results is necessary before the project moves into implementation. Implementation Phase - Everything is ready and it's time to go live. Training takes place, everyone who will use the system must be fully informed of the day it goes live, previous data is migrated, and the system is ready for use. After it goes live, the system is reviewed postimplementation to see how well it worked and how well the project went. It's often known as a debriefing or lessons learned meeting. It is also where any problems that
  • were not crucial to the implementation can be addressed and any necessary changes to the system documented for future versions. Operations and Maintenance Phase - Hey, it's not over. Just like a car engine, maintenance and support are necessary. What happens if the system is based on Microsoft NT 4.0 and 2 years later Microsoft is no longer supporting NT 4.0? Or, a new e-mail program is put in place and it interferes with the system? Fixes are necessary and will occur. This is the day-to-day operation of the software. No one can just walk away once the software is rolled-out and say, "Whew, glad that's over." It's not over; it's just begun. Disposition Phase - This is where the system has become obsolete. Perhaps a whole new system is coming in, or this system cannot keep up. Many programs and systems became obsolete with the Y2K problem or with upgrades of operating systems. Whatever the reason, putting the system to bed involves more than just shutting off the server. Often, the system may be kept going due to regulatory issues or because there are still projects using it. Even if the system will be shut down due to the development of a better system, disposition needs planning. A disposition plan, archiving of system documentation, archiving of data, even a plan for getting rid of the old equipment may be a part of the Disposition Phase. This is a short description of SDLC and its phases. The important idea to take away from SDLC is that it involves planning, approval, testing, and documentation to assure that the system can, and will work as required Lecture 2 System Development Models 1. Waterfall / Linear-Sequential / Classical 2. RAD (Rapid Application Development) 3. Prototype 4. Incremental
  • 5. Spiral 1. Waterfall / Linear-Sequential / Classical  It is sometimes called the classic life cycle or the linear sequential model.  Because of the cascade from one phase to another, this model is known as the „waterfall model‟ or software life cycle. Waterfall Steps: Requirements analysis and definition The system‟s services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. System and software design The systems design process allocates the requirements to either hardware or software systems by establishing an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. Implementation and unit testing During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification. Integration and system testing The individual program units or programs are integrated and tested as a complete system to ensure that the software
  • requirements have been met. After testing, the software system is delivered to the customer. Operation and maintenance Normally (although not necessarily), this is the longest life cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system‟s services as new requirements are discovered. Advantages: • 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, does not 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 to documents, ”swimming upstream”. Significant administrative overhead, costly for small teams and projects. 2. Incremental Model  Incremental software development, which is a fundamental part of agile approaches, is better than a waterfall approach for most business, ecommerce, and personal systems.  Incremental development reflects the way that we solve problems. We rarely work out a complete problem solution in advance but move toward a solution in a series of steps, backtracking when we realize that we have made a
  • mistake. By developing the software incrementally, it is cheaper and easier to make changes in the software as it is being developed.  Each increment or version of the system incorporates some of the functionality that is needed by the customer. The customer can evaluate the system at a relatively early stage in the development to see if it delivers what is required. If not, then only the current increment has to be changed and, possibly, new functionality defined for later increments. Incremental development has three important benefits, compared to the waterfall model: 1. The cost of accommodating changing customer requirements is reduced. The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. 2. It is easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented. Customers find it difficult to judge progress from software design documents. 3. More rapid delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included. Customers are able to use and gain value from the software earlier than is possible with a waterfall process.
  • OR Advantages of Incremental model:  Generates working software quickly and early during the software life cycle.  More flexible – less costly to change scope and requirements.  Easier to test and debug during a smaller iteration.  Customer can respond to each built.  Lowers initial delivery cost.  Easier to manage risk because risky pieces are identified and handled during it‟d iteration. Disadvantages of Incremental model:  Needs good planning and design.  Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.  Total cost is higher than waterfall. 3. Prototyping A prototype is an initial version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions. Rapid, iterative development of the prototype is essential so that costs are controlled and system stakeholders can experiment with the prototype early in the software process.
  • A software prototype can be used in a software development process to help anticipate changes that may be required: 1. In the requirements engineering process, a prototype can help with the elicitation and validation of system requirements. 2. In the system design process, a prototype can be used to explore particular software solutions and to support user interface design. 3. The prototype is evaluated by the customer/user and used to refine requirements for the software to be developed. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done. Advantages of Prototyping Model 1) When prototype is shown to the user, he gets a proper clarity and 'feel' of the functionality of the software and he can suggest changes and modifications. 2) This type of approach of developing the software is used for non-IT-literate people. They usually are not good at specifying their requirements, nor can tell properly about what they expect from the software. 3) When client is not confident about the developer's capabilities, he asks for a small prototype to be built. Based on this model, he judges capabilities of developer. 4) Sometimes it helps to demonstrate the concept to prospective investors to get funding for project. 5) It reduces risk of failure, as potential risks can be identified early and mitigation steps can be taken. 6) Iteration between development team and client provides a very good and conductive environment during project. 7) Time required to complete the project after getting final the SRS reduces, since the developer has a better idea about how he should approach the project. Disadvantages of Prototyping Model: 1) Prototyping is usually done at the cost of the developer. So it should be done using minimal resources. It can be done using Rapid Application Development (RAD) tools.
  • Please note sometimes the start-up cost of building the development team, focused on making prototype, is high. 2) Once we get proper requirements from client after showing prototype model, it may be of no use. That is why; sometimes we refer to the prototype as "Throw-away" prototype. 3) It is a slow process. 4) Too much involvement of client is not always preferred by the developer. 5) Too many changes can disturb the rhythm of the development team. 4. RAD model  Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle  The RAD model is a “high-speed” adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a “fully functional system” within very short time periods.
  • RAD approach includes: 1. Business modeling 2. Data modeling 3. Process modeling 4. Application generation 5. Testing and turnover Advantages Flexible and adaptable to changes Can handle large projects without a doubt RAD realizes an overall reduction in project risk RAD realizes an overall reduction in project risk. Generally Rad incorporates short development cycles.
  • Disadvantages Requires more resources and money to implement RAD For large but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams. All applications are not compatible with RAD RAD is not appropriate, technical risks are high Need both customer and developer commitments to complete a project. Otherwise RAD will fail 5. Spiral Model The spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. It provides the potential for rapid development of incremental versions of the software. Using the spiral model, software is developed in a series of incremental releases. Advantages • 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 Disadvantages: • 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)