Notion of a Project
Notes from OOSE Slides – modified
These are essentially from Chapter 1. Read/review
carefully and understand.
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
 Already developed – but may need tailoring!
 Provide significant functionality.
►Benefit
are:
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
 Obtaining input from as many sources as possible
►Requirements
analysis
 Organizing the information
►Requirements
specification
 Capturing how the software should behave
►Likely
contains a Domain11Model
5
Interviewing the Client
►
►
►
►
►
►
►
►
►
What is your vision for the Application?
How will it be used?
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
Reports needed? Online retrievals needed? Backup?
Anticipated risks? (technical, personnel, environmental, budget, support…)
MORE!!
11
6
Activities Common to Software
Projects...
►Design
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
7
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
8
Difficulties and Risks in Software
Engineering
► 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…
11
9
Difficulties and Risks in Software
Engineering
►•
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
10
►•
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.
 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
11
►
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
12