1. 111 Notion of a Project Notes from OOSE Slides – a different textbook used in the past Read/review carefully and understand.

2. 112 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

3. 113 Software Engineering Projects ► ‘Green field’ projects  New development  The minority of projects  Arguable…

4. 114 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.

5. 115 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

6. 116 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!!

7. 117 Activities Common to Software Projects... ► Design (The ‘hows.’ The Solution Space.)  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 ► Database design ► Functional design

8. 118 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)

9. 119 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, ALL have 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…

10. 1110 Difficulties and Risks in Software Engineering (2/2) 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 software architecture 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 ►

12. 1112 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!