1 / 27

Software Engineering Management

Understand the fundamental assumption that good processes lead to good software. Explore risk management and how to reduce risks in software projects. Dive into the software process stages, including the Waterfall Model and iterative refinement. Learn about Feasibility Study, Requirements Analysis, Design, Testing, and Maintenance phases.

willyc
Download Presentation

Software Engineering Management

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Engineering Management Lecture 1 The Software Process

  2. Software Process Fundamental Assumption: Good processes lead to good software Good processes reduce risk

  3. Risk Management What can go wrong in a software project? How can the risk be reduced?

  4. The Software Process (Simplified) Feasibility and Planning Requirements Design Operation and Maintenance Implementation

  5. The Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance

  6. Requirements Analysis and Definition The system's services, constraints and goals are established by consultation with system users. They are then defined in a manner that is understandable by both users and development staff. This phase can be divided into:  Feasibility study (often carried out separately)  Requirements analysis  Requirements definition  Requirements specification

  7. System and Software Design System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture Software design: Represent the software system functions in a form that can be transformed into one or more executable programs  Unified Modeling Language (UML)

  8. Programming and Unit Testing The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified.) Individual components are tested against specifications.

  9. Integration and System Testing The individual program units are:  integrated and tested as a complete system  tested against the requirements as specified  delivered to the client

  10. Operation and Maintenance  Operation: The system is put into practical use.  Maintenance: Errors and problems are identified and fixed.  Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment.  Phase out: The system is withdrawn from service.

  11. Discussion of the Waterfall Model Advantages:  Process visibility  Dependence on individuals  Quality control  Cost control Disadvantages: Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised.

  12. Feedback in the Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance

  13. Iterative Refinement(Evolutionary Development) Concept: Initial implementation for user comment, followed by refinement until system is complete.  Vaporware: user interface mock-up  Throw-away software components  Dummy modules  Rapid prototyping  Successive refinement

  14. Iterative Refinement Requirements Evaluation Implementation (prototype) Design

  15. Iterative Refinement Concurrent Activities Initial Version Requirements Outline Description Intermediate Versions Design Implementation Final Version

  16. Iterative Refinement & Software Process Concurrent Activities Outline Description Requirements Design Implementation Final Version

  17. Observations about Software Processes Completed projects should look like the Waterfall Model but ... the development process is always partly evolutionary. Risk is lowered by:  Prototyping key components  Dividing into phases  Following a visible software process  Making use of reusable components

  18. Feasibility Study Before beginning a project, a short, low-cost study to identify • Client • Scope • Potential benefits • Resources needed: staff, time, equipment, etc. • Potential obstacles Where are the risks? How can they be minimized?

  19. Feasibility Study A feasibility study leads to a decision: go ahead do not go ahead think again In production projects, the feasibility study often leads to a budget request. In research, a feasibility study is often in the form of a proposal.

  20. Class Projects What are you going to create and why?

  21. The Client In this class, you have two clients: • Your fellow students in the class • The professor for the course Can you satisfy them both?

  22. Project Scope What are the boundaries of the team projects? • Must be completed in fifteen weeks • Need a prototype that demonstrates main features

  23. Potential Benefits • Why are you doing this project? • Examples • • Create a marketable product • • Improve the efficiency of an organization • • Control a system that is too complex to control manually • • New or improved service • • Safety or security • Get a good grade in this class

  24. Resources Examples: Staff: 3 to 5 students, with some help. How many hours per week? What skills do people have? Time: Must be completed by end of semester, including operational prototype, documentation, presentation Equipment and software: What special needs are there? Client: Will the client be sufficiently available and helpful?

  25. Obstacles Class Projects Start-up time. Creating a team, scheduling meetings, acquiring software, learning new systems, ... Business considerations. Licenses, trade-secrets, ... Too ambitious. Nothing to show at the end of the semester. Changing circumstances. Team members drop the class, ... What else?

  26. How to Minimize Risk? Class Projects • Several target levels of functionality: required, desirable, optional • Visible software process: intermediate deliverables • Good communication within team and with the professor Good processes lead to good software Good processes reduce risk

  27. Project Topic Statement • A description of your group’s project selection • • Each group needs to pick a name. Hand in one sheet that lists the group name and its members. • Each group needs to submit a project topic. This is an informal write-up that describes what the team is going to build. • • Short enough that everybody reads it • • Long enough that no important details are skipped

More Related