Unit 2 : Software Process O b j ec t i ve This unit introduces software systems engineering through a discussion of software processes and their principal characteristics. In order to achieve the desireable p r od u c t characteristics given in the preceding Unit it is necessary to have a disciplined engineering process. W h a t is a Proc e s s? a set of ordered tasks i n v ol v in g a c t iv i ti e s, c o ns t r a in t s a n d resources that produce an intended output of some kind a process is i m po r t an t b e c au s e i t i m p os e s co n s is t e n cy an d structure on a set of activities it guides our actions by allowing us to examine, understand, control and improve the activities that comprise the process the process of bui l di n g a pr o du c t i s s om e t i me s c al l e d a lifecycle because it describes the life of that product from conception through to its implementation, delivery, use and m a in t e n an c e 2Ñ1
Software Process Models there are many process model s in th e li t e ra t u re, s om e a r e prescriptions and some are descriptions you need to model t h e p r o ce s s be c a use: Ðwhen a team wri t es do w n a d e s cr i p t io n o f i t s d e ve l op m e n t process it forms a common understanding of the activities, resources and constraints involved in software development Ðcreating a process model helps the team find inconsistencies, redundancies and ommissions in the process, as these problems are noted and corrected the process becomes more effective Software Process Models (continued) Ðthe model re f le c t s t h e g o al s o f d e ve l o pm e n t a n d s h o ws explicitly how the product characteristics are to be a c hi e v ed Ðeach develo p m en t is di f fe r e n t a n d a p r o ce s s ha s to be tailored for different situations, the model helps people to understand these differences 2Ñ2
57 Varieties there are very many di f fe r e nt w ay s o f o r ga n is i n g t h e s o f tw a r e development process, each appropriate to different situations the foll o wi n g a r e s o m e m o d el s or li f e cy c les because these are very hi g h- l e ve l c h a ra c te r i s at i on s t he y a r e often called p a r ad i gm s, some examples follow Waterfall Model I r eq u ir em en ts a n al ys i s p ro gr a m c od in g unit testing a c ce pt an c e operation & m a in te an ce 2Ñ3
Waterfall Model II r eq u ir em en ts a n al ys i s p ro gr a m c od in g unit testing a c ce pt an c e operation & m a in te an ce Waterfall Model III r eq u ir em en ts a n al ys i s p ro gr a m c od in g unit testing a c ce pt an c e operation & m a in te an ce 2Ñ4
V-Model r eq u ir em en ts validate requirements a n al ys i s verify design p ro gr a m c od in g unit testing a c ce pt an c e Exploratory Model develop outline s p ec i fi ca t io n build software use software n o test adequacy y es d el iv er 2Ñ5
Prototyping Model establish outline s p ec i fi ca t io n d ev el op p ro to ty p e e va lu a te p ro to ty p e s p ec i fy c om p on en ts design and implement system n o validate system RAD Model t ea m 1 b u si ne s s d a ta t ea m 2 b u si ne s s d a ta b u si ne s s p ro c es s a p pl ic a ti on g en er at io n testing & t ur no v er 60-90 days t ea m 3 d a ta p ro c es s a p pl ic a ti on g en er at io n testing & t ur no v er p ro c es s a p pl ic a ti on g en er at io n testing & t ur no v er 2Ñ6
Incremental Model c on c ep tio n a r ch it ec tu re s tr u ct ur e deliver 1st i nc r em e nt a n al ys i s c od e t es t f e ed b a c k deliver 2nd i nc r em e nt a n al ys i s c od e t es t f e ed b a c k deliver nth i nc r em e nt a n al ys i s c od e t es t Formal Development Model c or r ec tn es s p re s er v in g t ra n sf o rm a tio n c or r ec tn es s p re s er v in g t ra n sf o rm a tio n high- level formal s p ec i fi ca t io n i nt er me d ia t e specification ( 1 ) i nt er me d ia t e specification ( 2 ) i nt er me d ia t e specification ( n ) c od e P proof of ÒsecurityÓ of t ra n sf o rm a tio n P f o rm a l d ev el op m en t r ec or d 2Ñ7
Spiral Model determine goals, a lt er na t iv es, c on s tr ai nt s a lt e rn at i ve s evaluate alternatives and risks b ud ge t p la n c o ns t ra in t s b ud ge t b ud ge t c o ns t ra in t s integration & test plan implementation plan c o ns t ra in t s a lt e rn at i ve s c o ns t ra in t s risk analysis b ud ge t development plan a lt e rn at i ve s a lt e rn at i ve s r e qu i re m en ts, life-cycle plan risk analysis concept of o pe r at io n v al i da te v er i fy a c ce p ta nc e t es t risk analysis risk analysis p r ot ot yp e p r ot ot yp e p r ot ot yp e software requirements s y st e m t es t software design u ni t t es t p r ot ot yp e c o de detailed design develop and test Where Should Effort Go? 2Ñ8
Phase Costs after Boehm phase costs % system type reqts/design implementation testing command & control systems spaceborne systems operating systems scientific systems business systems 46 20 34 34 20 46 33 17 50 44 26 30 44 28 28 you can make what you like of this kind of thing Key Points A di s c i pl i ne d d e v el o pm e n t p r oc e s s i s t he co r n er s t o ne of software engineering. Different processes are appropriate in different circumstances. Regardl e s s o f t h e p r o ce s s t o be ad o pt e d i t s h o ul d a l wa y s be explicitly documented and the entry and exit criteria of all the constituent activities should be set down clearly. 2Ñ9