1 / 12

Notion of a Project

Notion of a Project. Notes from OOSE Slides – a different textbook used in the past Read/review carefully and understand. Software Engineering Projects. Many projects are evolutionary or maintenance projects, involving work on legacy systems Corrective (remedial) projects: fixing defects

jbethany
Download Presentation

Notion of a Project

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. Notion of a Project Notes from OOSE Slides – a different textbook used in the past Read/review carefully and understand. 11

  2. Software Engineering Projects • Many projects are evolutionary or maintenance projects, involving work on legacy systems • Corrective (remedial) projects: fixing defects • Adaptive projects: changing the system in response to changes in • Operating system • Database • Rules and regulations; new / different requirements… • Enhancement projects: adding new features for users • Reengineering or perfective projects: changing the system internally so it is more maintainable 11

  3. Software Engineering Projects • ‘Green field’ projects • New development • The minority of projects • Arguable… 11

  4. Software Engineering Projects • Projects that involve building on a framework or a set of existing components. • The framework is an application that provides many features but is missing some important details (on purpose). • Such projects: • Involve plugging together components that are: • Already developed – but may need tailoring! • Provide significant functionality. • Benefit from reusing reliable software. • Provide much of the same freedom to innovate found in green field development. 11

  5. Activities Common to Software Projects • Requirements and specification • Includes • Domain analysis (must understand the business / scientific environment within which your application will be running and providing support!) Understand business ‘entities.’ • Defining the problem (to be accommodated…) • Requirements gathering • Obtaining input from as many sources as possible; stakeholders • Requirements analysis • Organizing the information • Requirements specification • Capturing how the software should behave • Likely contains a Domain Model 11

  6. Interviewing the Client(The Problem Space) • What is your vision for the Application? • How will it be used? (stakeholders have widely differing views/expectations. • Who will be the end users? Their characteristics? • What will the inputs be? • What will the outputs be? • What are the expected processes? • What kind of interface do you envision? • What kind of storage structures are needed? • Reliability? Scalability? Platforms? IT constraints? • Languages, development / maintenance environments, … • Time frame when needed? • Degree of customer collaboration? • Set this up and the mechanism for interchange. • Major subsystems (for design) from customer view (Core areas??) • Reports needed? Online retrievals needed? Backup? • Anticipated risks? (technical, personnel, environmental, budget, support…) • MORE!! 11

  7. Activities Common to Software Projects... • Design (The ‘hows.’ The Solution Space.) • Deciding howthe requirements should be implemented, using the available technology • Includes: • Systemsengineering: Deciding what should be in hardware and what in software (not in this course) • Softwarearchitecture: Dividing the system into subsystems and deciding how the subsystems will interact • Detaileddesign of the internals of a subsystem • Userinterface design • Database design • Functional design 11

  8. Activities Common to Software Projects (continued) • Modeling • Creating representations of the business domain • (Domain Modeling should precede these activities…) • Use case modeling (Requirements) • Structural modeling (Analysis and Design) • Dynamic and behavioral modeling (Analysis and Design) • Programming • Quality assurance • Reviews and inspections • Testing • Deployment • Managing the process (Change/Configuration) 11

  9. Difficulties and Risks in Software Engineering (1/2) • Risk Analysis is a key feature in all software development projects. • Everything we do or change, such as new technologies, new requirements, new personnel, ALLhave associated risk and need to be assessed. • Risk must be addressed: mitigated, accepted, out-sourced, but not ignored! • may be technology-related, training-related, organizationally-related, environmentally-related… 11

  10. Difficulties and Risks in Software Engineering (2/2) • • Complexity and large numbers of details • A major concern as features are ‘added.’ • Design for flexibility by ensuring the softwarearchitecture has identified subsystems, etc. • Keep it simple and be careful about accepting change. Are they really necessary? • • Uncertainty about technology • Use proven technologies; try out new technologies by prototyping; ensure capturing user requirements via prototyping…. 11

  11. More Uncertainty, Difficulties • • Uncertainty about requirements • Attempt to understand the application domain as completely as possible in order to communicate with clients and other users. • Prototype to get good feedback on potential problems and requirements that might be unclear. • Expect change; design with change in mind. • Encourage user involvement. • • Uncertainty about software engineering skills • Ensure people are trained in the technologies!!! • Provide mentoring from senior developers • • 11

  12. More Uncertainty, Difficulties • Constant change • Both technology and requirements will change! • Try to distinguish the really important changes from those lesser • Will have to work with customer on these – most likely. Tradeoffs! • • Deterioration of software design • Design can become horrible from successive changes if your design is not built for flexibility and change. • Approach Change with respect but with caution. Be certain to understand the change. • • Political risks • Will be difficult to satisfy everyone. • Try to promote the products. • Recognize how the system will affect all stakeholders. • Above all, have fun! 11

More Related