0% found this document useful (0 votes)
3 views5 pages

SOFTWARE PROCESSES Unit 1 Chapter 3

software engineering
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views5 pages

SOFTWARE PROCESSES Unit 1 Chapter 3

software engineering
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

SOFTWARE PROCESSES

REQUIREMENTS WORKFLOW:

1. Aim: for development organization to determine the client’s needs.


2. Team acquire a basic understanding of the application domain( the specific
environment in which the target product is to operate)
3. Vital aspect of software development is the business model( doc
demonstrating the cost effectiveness of target product)
4. At an initial meeting btw client and developers , client outlines the product
5. Developers is to determine exactly the client’s needs and find out from the
client what constraints exist.
6. Constraints : Deadline: Client needs the product for core activities of its
organization and delay in delivering the target product is detrimental to the
org.
7. Reliability; Size of the executable load image ; cost
8. The preliminary investigation of the client’s needs sometimes is called
concept exploration.
9. In meetings between client and developers , functionality of the product
proposed is successively refined and analyzed for technical feasibility &
financial justification.
10.Stock control system is required

ANALYSIS WORKFLOW

1. Aim: Analyze and refine the requirements to achieve the detailed


understanding of the requirements essential for developing a product
correctly and maintaining.
2. If rest develop a product by continuing with further iterations of requirement
workflow until necessary understanding of target product obtained.
3. Constraints: Miscommunication btw client and developers regarding
requirements and consequently product developed to satisfy those
requirements may not be what the client needs.
4. Sol: to have two separate workflows 1) requirements couched in the clients
language; analysis in more precise language that ensures design and
implementation is carried out correctly.
5. more details added during analysis , details relevant that are essential for
developers.
6. Specification essential for both testing & maintenance , should be written as
if evidence for the trial. Specifications are ambiguous and incompleteness is
another problem in this.
7. Once client approved, detailed planning and estimating commences.
8. For developers , merely estimating the duration and total cost is not enough.
The developers need to assign. the appropriate personnel to various
workflows of development process.
9. Implantation cannot start without approval of SQA team
10.SPMP(Software project management plan) must be drawn up that reflects
separate workflows of development processes and shows which embers of
organization are involved in which task as well as the deadlines in each task

Major components of the plan are deliverables ( client is going to get) ,


milestones ( when client gets them), and budget( cost it’s going to cost)

11.The plan describes the process in full detail.( life cycle model used , org
structure, responsibilities managerial objectives etc)

DESIGN

1. Aim: refine the artifacts from analysis until material I in the form that can be
implemented by the programmers
2. The team determines internal structure of the product
3. The product is broken down into two modules. Interface of each module
must be specified in detail.
4. Once team completed the decomposition ( architectural design), detailed
design is performed
5. For each module alga are selected and data structures are chosen
6. Class( specific module type) are extracted during analysis and designed
during design
7. Architectural is performed as a part of the object oriented analysis workflow
8. Detailed design is performed as object oriented design workflow.
9. A design team must keep a meticulous record of the decisions that are made
here
I) while product being designed a dead end may be reached at times and the
team must back track nod redden the certain parts.
ii)A design should be open ended for future enhancements that can be done
by introducing or removing classes without affecting the whole product
design.
iii)designers have to compromise putting together a design that can be
extended in many ways without need of total redesign

IMPLEMENTATION

1. Aim: implement the product in the chosen implementation languages.


2. Large software product is portioned into smaller sub systems which then are
implemented in parallel by coding teams.
3. Subsystems consists of components / code artifacts implemented by a
programmer.

TEST

1. Unified process testing is carried out in parallel with other workflows from the
beginning.
2. 2 major aspects:
i) Every developer and maintainer is personannly responsible for
ensuring that its work is correct and therefore has to test and retest
each artifact they develop or maintain.
ii) Once professional is convince that artifact is correct , it is handed over
to the SQA group for independent testing.
3. Nature of the test workflow changes depending on the artifacts being tested.
(more info from try notes)

POST DELIVERY MAINTENANCE

1. It’s an integral part that must be planned from the start.


2. More money than other stages is spent here.
3. Testing changes done here :
i) Check that required changes have been implemented correctly
ii) Ensuring wart to the need changes that other inadvertent
changes were made
iii) Product then tested again sty previous test cases to check the
functionality of the product is not compromised. ( regression
testing)
4. Then record all changes made together with a reason for each change

RETIREMENT

1. Final step where post delivery maintenance no longer cost effective,


i) Proposed changes so drastic that design as a whole has to be changed
( waste of money)
ii) Many changes make the original product less effective wart its
functionality as a whole
iii) Documentation may not have been adequately maintained , increasing
risks of a regression fault that its safer to recode than maintain
iv) The hardware on which the product runs is to be replaced
2. True retirement ( rare) occurs when product has outdone its usefulness, and is
removed from the device
CAPABILITY MATURITY LEVELS

1. CMM of SEI( Software Engineering Institute) are a related group of strategies


for improving the software processes irrespective of actual life cycle model
used.
2. Developed CMMs for software ( SW-CMM)
3. The strategy of SW-CMM is to improve management of software processes in
the belief that improvements in technique are a natural consequence
4. Result should be better quality software and should not suffer from time and
cost overruns.
5. Five levels of maturity are defined
i) Lvl 1: initial level:
a) everything done on ad hoc basis.
b) Specific project staffed by a competent manager and a good sw team
may be successful.
c) However time and cost overruns caused by lack of sound
management and planning.
d) Most activities are in response to crisis rather than preplanned tasks.
e) Sw process unpredictable( depends totally on current staff as staff
changes)

ii) Lvl 2 : repeatable lvl:


a) basic sw project management are in place.
b) planning and management techniques bases on experience with
similar products ( hence repeatable)
c) first measurement taken( cost tracking and schedules)
d) Managers arise the problem and take immediate action to prevent
them from becoming crisis.
e) Measurements taken during one project can be used to draw up
realistic duration and cost schedules for future projects.

iii) Lvl 3: defined lvl:


a) Process fully documented. Both managerial and technical aspects
clearly defined
b) Continual affords to improve the process.
c) New technology( CASE Environment) to increase quality and
productivity.

iv) Lvl4: Managed lvl:


a) Sets quality and productivity as goals for each project.
b) These two quantities are measured continually and corrective
action is tank when deviations from the goal occur.
c) Statistic quality control are in place to enable management to
distinguish a random deviation.
v) Lvl 5: optimizing lvl
a) Goal is continuous process improvement
b) Statistical quality and process control techniques used to guide
c) Incorporates a positive feedback loop, resulting steady
improvement in productivity and quality.

i. For each level SEI has highlighted a series of key process areas( KPAs)
ii. These areas cover basic elements of software management( determine
clients needs, draw up a plan, monitor product ( configuration),ensure fault
free product( quality assurance)
iii. At level 5 KPAs include, fault prevention, tech change management process
change management.

You might also like