Notion of a Project

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