What special for .net project in Software Development Life Cycle?

[athos]

Hi all,

Believe you have sound experience in development, however, if we look
at the whole Software Development Life Cycle (SDLC) of the project,
say,

1. Project Initiation,
2. Gathering Requirements,
3. System Analysis and Design,
4. System Development,
5. System Testing (SIT/UAT),
6. Project Implementation,
7. Post Implementationcoding,

deveopment is just one of them. Of course, in development stage, if the
project is going to be done in .net, there are lots of "tricks" or
"tips". But, for other stages, is there any special points shall we pay
attention to, if we choose .net?

Previously I raised this question for the 2nd stage, "Gather User
Requirement", John Timney (MVP) kindly replied

"None. Your requirements capture should focus on whats trying to be
achieved only. The technical choice should be made as a result of
trying to identify a technical solution to the requirement, if a
technical solution is the right choice, simple process change can
sometimes be the solution.

"Dont get caught in the trap of trying to mould a requirement around a
preferred technical solution - its the bain of bad design. "

I agree with him that technical solution should be the result of trying
to address users' requirments. However, if BEFORE anything happens,
".net" approach has been decided, or, let's imagine you are in a .net
software house, you won't be able to choose vb6 or vba or java or perl,
let's suppose this has been determined before any project initiates,
..... then for the whole life circle, is there any special points that
you guys may be sensitive?

For example, in "3. System Analysis and Design" stage, will you guys
focus more on bandwidth and response time requirement? Or, for "5.
System Testing (SIT/UAT)" stage, will you guys especially consider
browser compatibility or cookie issue? Or, in "6. Project
Implementation" stage, will you guys attach some manual for .net
framework packup?

any such "tips" or "tricks", any ideas guys?

Thanks.

 

[Nick Malik [Microsoft]]

Hello Athos,

However, if BEFORE anything happens,
".net" approach has been decided, or, let's imagine you are in a .net
software house, you won't be able to choose vb6 or vba or java or perl,
let's suppose this has been determined before any project initiates,
.... then for the whole life circle, is there any special points that
you guys may be sensitive?

No. John was correct. these choice of language has absolutely no impact on
the SDLC method chosen or how it is implemented. It will have an impact on
the projects' productivity with respect to the skill sets of the team.
Therefore, if your team is familiar with Perl coding, then doing the project
in .Net may not produce a high productivity. On the other hand, the SDLC
isn't fundamentally altered... just it's likelihood of success.

For example, in "3. System Analysis and Design" stage, will you guys
focus more on bandwidth and response time requirement?

This goes to the skill of the developers and the techniques used... NOT the
development process. Whether the process is iterative or waterfall, the
steps are the same regardless of the activity performed in them.

Or, for "5.
System Testing (SIT/UAT)" stage, will you guys especially consider
browser compatibility or cookie issue? Or, in "6. Project
Implementation" stage, will you guys attach some manual for .net
framework packup?

Perhaps I have not correctly understood the underlying situation. That is
possible. I will take a different approach to understanding your question.

I'm guessing that you have a project team that is not particularly familiar
with .Net development, and you want advice about the likely "gotchas" that
an inexperienced developer will want to focus upon when writing their first
..Net app. Is this the actual question?

I think that you will find that the "gotchas" in any platform, whether it is
..Net development in C# or J2EE development or Smalltalk or Perl, etc, are
not the problems that kill the project. In other words, you are probably
solving the wrong problem. You want to make sure that they "build the
system right," when you should focus on "building the right system." That
is because an inexperience team is unlikely to do a good job of planning,
envisioning, and requirements gathering. Their lack of knowledge in .Net
will be the least of your worries if they build the wrong system.

In other words, your apparent intention of developing generic advice for an
inexperienced team is, IMHO, a waste of effort. It would be better to send
the novices to certification training and to get a couple of experienced
folks to come help out.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--