Notion of a Project
Notes from OOSE Slides – a different textbook used in the past
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; new / different requirements…
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
Arguable…
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.
are:
►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!) 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 11Model
5
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
6
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
11
7
►Functional design
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 (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…
11
9
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
10
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
11
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
12