CH Two Software Process Model
CH Two Software Process Model
CH Two Software Process Model
Software specification
Define a set of services required from the system
Identify constraints on the systems operation and development
Four basic activities of a software specification
oFeasibility study(achievable? Cost effective?)
oRequirements gathering(through observation and discussion)
oRequirement specification
oRequirement validation( checks the requirements for consistency, and
completeness)
Cont’d
Developing software without planning for each phase, and without specifying
tasks, deliverables, or time constraints.
Relies entirely on the skills and experience of the individuals performing the work.
3 2
Customer Build /
Test-Drives Revise
prototypes prototypes
Paper prototyping
Why prototyping?
oGet user feedback early
* Use it to focus the development process
oSave time and money
* Solve key problems before implementation begins
oCommunicate better
* Involve development team members from a variety of disciplines
oBe more creative
* Experiment with many ideas before committing to one
Paper prototyping
Sketches of the interfaces
Limited in details
o Limited color
o Limited graphics
o Limited content
How to create a paper prototype?
o By hand drawing
o Cutting/pasting/glueing/…
o Changes are made easily
* All you need is a pencil and an eraser
3)Component-Based Models CBSE
Development System
and integration validation
Web services that are developed according to service standards and which
are available for remote invocation.
Collections of objects that are developed as a package to be integrated with
a component framework such as .NET or J2EE.
Stand-alone software systems (COTS) that are configured for use in a
particular environment.
4) Iterative Models
Incremental development model
principle
oDevelop initial implementation of the software
oGive it to the user for comment
oImprove it through several versions
Specification, development, and validation activities are
interleaved rather than separate, with rapid feedback across
activities.
Cont’d
Problems
Lack of process visibility;
Systems are often poorly structured;
Special skills (e.g. in languages for rapid prototyping) may be
required.
hard to identify common facilities that are needed by all increments.
Iterative development can also be difficult when a replacement system
is being developed
Applicability
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.
Spiral development
➢ Its spiral structure gives stakeholders a lot of points for review and
making “go” or “no-go” decisions.
➢ It emphasizes risk analysis. If you identify and resolve risks correctly, it
should lead to eventual success.
➢ It can accommodate change reasonably well. Simply make any
necessary changes and then run through a cycle to identify and resolve
any risks they create.
➢ Estimates such as time and effort required become more accurate over
time as cycles are finished and risks are removed from the project.
Disadvantages:
➢ It’s complicated.
➢ Because it’s complicated, it often requires more resources than simpler
approaches.
➢ Risk analysis can be difficult.
➢ The complication isn’t always worth the effort, particularly for low‐risk
projects.
➢ Stakeholders must have the time and skills needed to review the project
periodically to make sure each cycle is completed satisfactorily.
➢ Time and effort estimates become more accurate as cycles are finished, but
initially those estimates may not be good.
➢ It doesn’t work well with small projects. You could end up spending more
time on risk analysis than you’d need to build the entire application with a
simpler approach.
Rational Unified Process(RUP)
Inception
o Scope of the project is defined :
* What needs to be included? And what needs not?
o Build a business case
* Is it cost effective?
o Obtaining stakeholder agreement
* Are the clients happy? Will they be committed with the project?
Elaboration
o Detail list of complete requirements is prepared
o General architecture of the system will be designed
o Possible risks of the project are assessed
o Project plan is prepared (schedule,…)
Construction :
odeals with the actual construction of the SW
*design
*programming
*Testing
oWorking SW is produced
Transition :
oMoving the SW from development community to user
community
oMaking the software to work on the real environment
oComplete user manual is also prepared
RUP good practice
➢ Resistance to change.
➢ Doesn’t handle large systems well.
➢ Requires more skilled team members.
➢ Requires access to scarce resources.
➢ Adds extra overhead if the requirements are known completely and correctly in
advance.
➢ Less managerial control.
➢ Sometimes results in a less than optimal design..
➢ Unpredictability.
Four Phases of RAD:
Requirements planning—
o During this phase, the users, executive champion, management,
team leaders, and other stakeholders agree on the project’s
general goals and requirements.
o The requirements should be specified in a general way so that
they don’t restrict later development unnecessarily.
o When the stakeholders agree on the requirements and the
project receives approval to continue, the user design phase
begins.
User design—
o The users and team members work together to convert the
requirements into a workable design.
o They use techniques such as focus groups, workshops,
prototyping, and brainstorming to come up with a workable
design.
Cont’d