This preview shows page 1. Sign up to view the full content.
Unformatted text preview: Notion of a Project
These are essentially from Chapter 1. Read/review carefully and understand.
Notes from OOSE Slides modified 11 1 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 Enhancement projects: adding new features for users Reengineering or perfective projects: changing the system internally so it is more maintainable
11 2 Software Engineering Projects
`Green field' projects New development The minority of projects 11 3 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 4 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!) Defining the problem (to be accommodated...) Requirements gathering Requirements analysis Obtaining input from as many sources as possible Organizing the information Requirements specification 11 Likely contains a Domain Model Capturing how the software should behave
5 Design Activities Common to Software Projects... Deciding how the requirements should be implemented, using the available technology Includes: Systems engineering: Deciding what should be in hardware and what in software (not in this course) Software architecture: Dividing the system into subsystems and deciding how the subsystems will interact Detailed design of the internals of a subsystem User interface design Design of databases 11 6 Modeling Activities Common to Software Projects (continued)
(Domain Modeling should precede these activities...) Use case modeling (Requirements) Structural modeling (Analysis and Design) Creating representations of the business domain Programming Dynamic and behavioral modeling (Analysis and Design) Quality Assurance Deployment Reviews and Inspections (continuous) Testing
11 7 Managing the process (Change/Configuration) Difficulties and Risks in Software Engineering (1 of 4) Risk Analysis is a key feature in all software development projects. Everything we do or change, such as new technologies, new requirements, new personnel, ALL have associated risk and need to be assessed. Risk must be addressed: mitigated, accepted, outsourced, but not ignored! may be technologyrelated, trainingrelated, organizationallyrelated, environmentally
11 8 Difficulties and Risks in Software Engineering (2 of 4)
Complexity and large numbers of details Design for flexibility by ensuring the software A major concern as features are `added.' architecture has identified subsystems, etc.
Uncertainty about Technology
Are they really necessary? Keep it simple and be careful about accepting change. Use proven technologies; try out new technologies by prototyping; ensure capturing user 11 9 Difficulties and Risks in Software Engineering (3 of 4) Uncertainty about Requirements Uncertainty about Software Engineering Skills 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. Expect change; design with change in mind. Encourage user involvement. Ensure people are trained in the technologies!!! Provide mentoring from senior developers
11 10 Difficulties and Risks in Software Engineering (4 of 4) Be on the lookout for: 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! 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. Deterioration of software design Political risks Will be difficult to satisfy everyone. Try to promote the products. Recognize how the system will affect all stakeholders.
11 11 Above all, have fun! ...
View Full Document
This note was uploaded on 10/04/2011 for the course CEN 6016 taught by Professor Bobroggio during the Fall '11 term at University of South Florida - Tampa.
- Fall '11