Monday, March 14, 2011
Tuesday, March 8, 2011
Saturday, March 5, 2011
Sunday, February 27, 2011
Sunday, February 20, 2011
Sunday, February 13, 2011
Friday, January 28, 2011
Assignment 2 Task 2
K-base SDLC

Theoretical SDLC
There are 3 types of model that KBase used in their software development
.
.
Offshore Delivery Model
Onsite Delivery Model
Hybrid Delivery Model
Onsite Delivery Model
Hybrid Delivery Model
Model:Offshore Delivery Model
&Model:Onsite Delivery Model
&
Model:Hybrid Delivery Model&
Strength :
Excellent Results: Clients can get high quality work from the quality offshore resources.
No extra Expense: Client doesn’t have to worry about the infrastructure needed to complete their task.
Access to the Most Optimal Resources: Client can have access to the best possible technology, skilled manpower and equipments, depending on their budgets.
Productivity: Project is not affected by time-zone difference.
Weakness:
Low Management Maturity.
Customer dont know what they really want.
Offshore team has to spend some extra amount of time for code deployment and delivery.
Customer dont know what they really want.
Offshore team has to spend some extra amount of time for code deployment and delivery.

Strength:
Face-to-face dealings with the client:
On Hand Information:
No chance of communication gap.
Minimum chances of alterations in later stages:
For the clients, less time-to market
On Hand Information:
No chance of communication gap.
Minimum chances of alterations in later stages:
For the clients, less time-to market
Strength:
Direct dealings with the client
Access to the most excellent resources
Great cost benefits
Best possible management of resources
Access to the most excellent resources
Great cost benefits
Best possible management of resources
Friday, January 21, 2011
Saturday, January 15, 2011
assignment 2 -task 1
*Extreme Programming:
| characteristics | strengths | weaknesses | applicability |
| *Pair programming - Ensures quality code. One programmer is thinking whether the approach will work, about testing, or ways to simplify the code while the other programmer writes the code. *Simple design - Keep the design as simple as possible for the moment and don't add features that ar not needed for current functionality. *Small releases - There is a short time between versions | *Emphasis on teamwork and communication: As with the TSP, this is very important in improving the performance of just about every software team. *Emphasis on customer involvement: A major help to projects where it can be applied. *Simple design: Though obvious, worth stressing at every opportunity | *as automated acceptance tests rather than specification documents leads to lack of necessary documentation. *Can be very inefficient—if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. *Only works with senior-level developers( no chance for junior worker to gain experience). | *Used in Project Management *Used in XP and Web Development *Used for situations when customers may not have a firm idea of what the system should look like |
assignment 2 -task 1
*Prototype model:
| Characteristic | Strengths | Weaknesses | Applicability |
| * A prototype (early estimation of final software product) is built for user to test by trying them out, as oppose from user just interpreting the design based from description. *The prototype will be rebuilt again for improvement based on user feedback. *This process will be done several times until an acceptable prototype is achieved to produce complete software product. | * Can ensure that the developer, user and customer have a common understanding of what is needed and what is proposed. * Can be used by users to describe and proved requirements that developers have not considered. * Prevents misunderstanding between developer, user and customer that might occur particularly in the requirement analysis phase. | *The focus on a limited prototype can distract developers from properly analyzing the complete project. * Developers have the tendency to build complicated prototype (that in the end they have to throw it away) and thus results in lengthy development time. *Using prototype model is very costly because developers need to build many prototypes before right prototype is attained. | * When the requirements are unclear. *Most beneficial to system that will have many interaction with users. * Especially good for designing human-computer interfaces. |
assignment 2 -task 1
*Spiral Model:
characteristics | strengths | weaknesses | applicability |
*A hybrid model that support process iteration. *Represented as spiral, each loop in the spiral representing a process phase. *Risk is explicitly taken into consideration. | *Risk reduction mechanisms are in place. *Supports iteration and reflects real-world practices. *Systematic approach. | *Hard to estimate time & budget at earlier stage. *Need specific expertise in risk evaluation and reduction for analysis. *Applicable only to large systems because it involve high costs in implementation. | *Internal development of large systems. *For smaller projects, the concept of agile software development is becoming a viable alternative. *Development of space exploration. |
assignment 2 -task 1
*Incremental Model:
characteristics | strengths | weaknesses | applicability |
*Easy the traumatic effect introducing completely new system all at once. *Combine elements of both linear and parallel process flow. *Highest priority requirements need to be settle early | *Early increment can be implemented with few people . *Provide clients flexibility in making their decision. *New project can be stopped at any time after the first cycle. | *The project may be unfinished with the cost and the schedule overruns. *Problem may arise pertaining to system architecture. *The basic requirement are address but supplementary features remain undelivered. | *Core product is well received and additional staff can be added to implement. *Useful when insufficient can be planed to manage technical risk. *Essential pars of the rational unified process |
Friday, January 14, 2011
Wednesday, January 5, 2011
Saturday, January 1, 2011
Subscribe to:
Comments (Atom)












